Java 7u4 webstart 安全异常:类与信任级别不匹配 [英] Java 7u4 webstart security exception: Class does not match trust level

问题描述

我们开始注意到，在 Java 7(特别是更新 4)中，我们所有的用户都开始在我们的 Webstart 应用程序中看到这一点:

We began to notice that with Java 7 (particularly with update 4), that all our users began to see this with our Webstart app:

[14:42:58,422] AWT-EventQueue-0(DEBUG) java.lang.SecurityException: class "CLASSNAME" does not match trust level of other classes in the same package
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.security.AccessController.doPrivileged(Native Method)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)...More

其中 CLASSNAME = 几乎每个类都从应用程序执行中的几个 jar 中随机点，破坏了几种行为.如果我们的用户使用 Java 6，他们没有问题！仅 7(更新 4).我们签署了所有的 jar，包括主应用程序 jar 和它的库 jar.即用户启动我们的 webstart 应用程序会看到蓝色盾牌，而不是黄色或红色.

Where CLASSNAME = pretty much every class at random points from several jars in the app execution, breaking several behavior. If our users were to use Java 6, they have no problems! Just 7 (update 4). We sign ALL our jars, both the main application jar and it's library jars. i.e Users launching our webstart app see the blue shield instead of yellow or red.

这显然是一个问题，因为用户现在更频繁地升级到 Java 7.我试图通过使用以前的安装(有效)或安装新的来强制我们的应用程序在用户机器上使用 Java 6.... 资源周围带有 j2se version="1.6" 标签，但这会导致它自己的可能最好将问题纳入其自己的线程(自动 jre 安装部分).

This is obviously an issue as users are more frequently now upgrading to Java 7. I have tried to force our app to use Java 6 on the user machine either by using a previous installation(works), or installing a new one....with the j2se version="1.6" tag around resources but this causes it's own problems that would probably be best to make into it's own thread (the auto-jre-installation part).

Oracle 是否使用 Java 7u4 破坏了 Webstart 安全性?我该如何解决这个安全异常问题?

Did Oracle break Webstart security with Java 7u4? How do I solve this securityexception issue?

推荐答案

只是 jarsigners hack check in 的原始作者.我被另一位开发人员指导到这里，我最初与他分享了 hack.

Just the orig author of the jarsigners hack checking in. I was directed here by another dev, to whom I originally shared the hack with.

根据他对此的持续调查，您需要将以下内容添加到对 hack 的调用中

Based on his continued investigation into this you will need to add the following to calls to the hack

callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar);

callNoArgMethod("getManifest", jar);
makeHardLink("manRef", jar, n);

清单调用不是这篇文章的解决方案的一部分.他们是在创建验收测试以重现问题时发现的.

The manifest calls were not part of the solution to this post. They were found when an acceptance test was created to repro the issue.

基于这个新信息，我们改变了我们的方法，我们现在使用反射来调用所有get"方法(需要调用 get 方法来初始填充软引用，如果它们尚未填充)

Based on this new info, we've changed our approach, we now use reflection to call all "get" methods (the calls to the get methods are required to initially populate the softreferences, if they aren't populated already)

然后反射性地发现 CachedJarFile 类中的所有软引用并创建指向它们的硬链接.

And then reflectively discover all softreferences in the CachedJarFile class and create hardlinks to them.

只要 CachedJarFile 保持原位并且 hack 的基本前提保持正确，这应该会在未来通过进一步的内部重命名/重构来证明解决方案.(即:将软引用变成硬引用.

This should future proof the solution from further internal renames/refactors, as long as the CachedJarFile stays in place and the basic premise of the hack stays true. (ie: make softreferences into hardreferences.

这篇关于Java 7u4 webstart 安全异常:类与信任级别不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！