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个）。我们签名所有的jar，包括主应用程序jar和库jar。即，启动我们的Webstart应用程序的用户看到的是蓝色的盾牌，而不是黄色或红色的盾牌。

这显然是一个问题，因为用户现在更频繁地升级到Java7。我试图通过使用先前的html" target="_blank">安装（工作）或安装新的安装来强制我们的应用在用户计算机上使用Java
6。在资源周围使用j2se version =“ 1.6”标签，但这会导致它自己的问题，最好将其纳入自己的线程中（auto-jre-
installation部分）。

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

Answer 1

只是jarsigners hack的原始作者签入。我是由另一个与我最初共享该hack的开发人员指导的。

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

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

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

清单调用不是此帖子解决方案的一部分。他们是在创建接受测试以重现该问题时发现的。

基于此新信息，我们已更改了方法，现在使用反射来调用所有“ get”方法（如果尚未填充软引用，则必须首先调用get方法来填充软引用）

然后反省地发现CachedJarFile类中的所有软引用，并为其创建硬链接。

只要CachedJarFile保留在原位，而hack的基本前提仍然成立，这将在将来证明该解决方案不受其他内部重命名/重构的影响。（即：将软引用转换为硬引用。