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

Question

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

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 1

I had the same problem with 1.7.07: my webstart application failed randomly with the same error message while loading classes. I found a interesting workaround on this page oracle forums. The last answer describes a workaround for the problem (Java 6) - the reference to the Signature of the jars are hold as soft reference and these may be garbage collected, and this causes the error message. This can be adopted for Java 7 with some additional lines

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

Answer 2

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.

Answer 3

I think you may be experiencing this bug.

The bug status says that a fix has been delivered in 7u4. But that doesn't jell with what you are saying. Perhaps the "fix" breaks ....

In the meantime, the comments on the bug by "squaat" mention possible workarounds. For instance, increasing the initial heap size and/or using a preloader to force some JARs to load earlier.

Answer 4

I've the same problem after updating to JRE 8 update 91. With previous releases 1.6, 1.7, 1.8 update 77 my applications runs fine.

Has Oracle reintroduced a bug that was present in JRE 1.6 bug?

The only work around that I've found is to disable mixed code control from Java Control Panel.

---

I fixed it. The problem was in a library used by my applications. The MANIFEST.MF present in the jar was this:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_07-87 ("Apple Computer, Inc.")
Built-By: wolf

Name: common
Specification-Title: swixml
Specification-Vendor: swixml.org
Specification-Version: 1.6
Implementation-Title: org.swixml
Implementation-Vendor: swixml.org
Implementation-Version: 1.6 beta 1 (#151)

The "Name" property is used for resource specific entries as stated here http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest

Signing this jar the "Name" entry is interpreted as a resource but there is no resource to sign. When the application is launched javaws finds a mismatch between the resources reported in MANIFEST.MF and the effective resources in the jar blocking the application