Java 7u4 webstart security exception: class does not match trust level
We began to notice that with Java 7 (especially update 4), all our users began to use our webstart application. See this:
[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.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 = random points in several cans of almost every class during application execution, breaking several behaviors If our users use Java 6, they have no problem! Only 7 (update 4) We sign all jars, the main application jar and its library jar That is, the user who starts our webstart application sees a Blue Shield instead of yellow or red
This is obviously a problem because users are now upgrading to Java 7. 0 more frequently I tried to force our application to use Java 6 on the user's computer, use the previous installation (work), or install a new Use J2SE version = "1.6" tag to surround the resource, but this will lead to its own problem that it may be best to enter its own thread (auto JRE installation section)
Did Oracle break webstart security through Java 7u4? How to solve this SecurityException problem?
Solution
Just the original author checked in by jarsigners hack I was led here by another developer, and I initially shared hacking with him
Based on his continuous investigation, you need to add the following to call hack
callNoArgMethod("getSigningData",jar);
makeHardLink("signingDataRef",jar);
callNoArgMethod("getManifest",jar);
makeHardLink("manRef",jar,n);
The manifest call is not part of the solution for this post They are found when acceptance tests are created to reproduce problems
Based on this new information, we changed our method. We now use reflection to call all "get" methods (if there is no padding, we need to call the get method to initially populate the soft reference)
Then reflexively discover all the soft references in the cachedjarfile class and create hard links for them
As long as the cachedjarfile remains unchanged and the basic premise of the hacker remains correct, this can prove the solution from other internal renaming / refactoring in the future (i.e. soft reference to soft reference