Java 7u4 webstart安全性异常:类与信任级别不匹配

Question

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

[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).我们签署所有的罐子,主要的应用罐子和它的库罐子.即启动我们的webstart应用程序的用户看到蓝色盾牌而不是黄色或红色.

这显然是一个问题,因为用户现在更频繁地升级到Java 7.我试图通过使用先前的安装(工作)或安装新的应用程序来强制我们的应用程序在用户计算机上使用Java 6 ....使用j2se version ="1.6"标记围绕资源,但这会导致它自己的问题,这可能是最好的进入它自己的线程(auto-jre-installation部分).

Oracle是否通过Java 7u4破坏了Webstart安全性？如何解决此securityexception问题？

Answer 1

我在1.7.07遇到了同样的问题:我的webstart应用程序在加载类时随机出现相同的错误消息.我在这个页面oracle论坛上找到了一个有趣的解决方法.最后一个答案描述了该问题的解决方法(Java 6) - 对jar的签名的引用被保存为软引用,这些可能是垃圾收集,这会导致错误消息.这可以用于Java 7以及一些额外的行

// Java 1.7
callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar); 

Answer 2

只是 jarsigners hack 的原作者签入。我是由另一位开发人员引导到这里的，我最初与他分享了 hack。

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

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

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

清单调用不是本文解决方案的一部分。它们是在创建验收测试以重现问题时发现的。

基于这个新信息，我们改变了我们的方法，我们现在使用反射来调用所有“get”方法（对 get 方法的调用需要最初填充软引用，如果它们尚未填充）

然后反思性地发现 CachedJarFile 类中的所有软引用并创建到它们的硬链接。

只要 CachedJarFile 保持不变并且黑客的基本前提保持正确，这应该可以通过进一步的内部重命名/重构来证明解决方案的未来。（即：将软引用变成硬引用。