Glstunna Glstunna - 1 year ago 60
Java Question

Java 7u4 webstart security exception: Class does not match trust level

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$ChildElement.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at$JarLoader.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at$JarLoader.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at$ Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at$ Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at Method)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at 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

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.

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).

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

Answer Source

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.

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)

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

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.