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

查看:148
本文介绍了Java 7u4 webstart安全性异常:类与信任级别不匹配的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们开始注意到,使用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 =几乎每个班级的随机点从应用程序执行中的几个罐子,打破了几个行为。
如果我们的用户使用Java 6,他们没有问题!只是7(更新4)。
我们签署所有罐子,包括主要的应用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标记围绕资源,但这会导致它自己的问题可能最好进入它自己的线程(auto-jre-installation部分)。

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安全性?我如何解决这个securityexception问题?

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

推荐答案

只是jarsigners hack签入的原始作者。我被另一个人引导到这里dev,我最初与之分享了黑客攻击。

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.

根据他对此的持续调查,你需要在黑客调用中添加以下内容

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方法,如果它们尚未填充)

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保持不变并且黑客的基本前提,这将来自进一步内部重命名/重构的解决方案保持真实。 (即:对软参考进行软参考。

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆