JNLP: Loading unsigned code within signed code

Question

We're having difficulties getting past the mixed code error for Java webstart. In summary, we have our main JNLP file, we've signed all of our code that it loads directly. We've added the all-permissions option to the main JNLP. The main class it loads also comes from a signed jar.

When the main class kicks off a little down the road it fires off some things that need to load some unsigned resources that are pulled in from JNLP B. None of JNLP B's resources are signed and they do not need any special permissions.

All of the signed code has been setup based on the mixed code documentation from Oracle and the jar files have been set with manifests of "Trusted-Library: true" before signing.

When the unsigned code is attempted to be loaded by the signed code we get a class not found error like so:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

    Caused by: java.lang.NoClassDefFoundError: org/some/external/package/that/is/not/signed
at org.our.signed.package.main(Main.java:87)
... 9 more

    Caused by: java.lang.ClassNotFoundException: org.some.external.package.that.is.not.signed
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 10 more

Here's the scenario in the JNLP's:

JNLP A: (summarized)

<jnlp spec="1.5+" codebase="...." href="......">
  <information>
   ...etc
  </information>
   <security>
     <all-permissions/>
   </security>
   <resources>
      <j2se version="1.6+" initial-heap-size="80m" max-heap-size="256m" href="http://java.sun.com/products/autodl/j2se"/>
      <jar href="signedJar_1.jar" download="eager" main="true"/>
      <jar href="signedJar_2.jar" download="eager" main="false"/>
      <extension name="unsigned_ext" href="unsigned.jnlp"/>
  </resources>
  <application-desc main-class="(FROM SIGNED CLASS in signedJar_1.jar)"/>
</jnlp>

JNLP B (the unsigned.jnlp loader)

<jnlp spec="1.5+" codebase="....." href="......">
  <information>
   ...etc
  </information>
  <resources>
    <jar href="unsigned.jar"/>
  </resources>
  <component-desc/>
</jnlp>

We have noted that the security exceptions are working correctly, because if we move the unsigned jar into the the JNLP that has all-permissions and has signed jars, we get the expected security exceptions that Java won't let us mix the signed code with Trusted-Library: true and unsigned code with no manifest attributes.

Ideas? Is there a reason the classloader can't find the java files from the unsigned code? Is there something special we are missing to allow signed code to run unsigned code? I've only seen the cases where people have problems getting unsigned code to run signed code, which I can understand.

Answer 1

The trusted-library class loader is a parent (in the sense of class loader delegation) of the (possibly untrusted) applet class loader. Think of it as if it is the boot class loader. So the untrusted classes can link to the trusted-library classes but not vice versa. Without going to the bother of altering manifests and using WebStart you can try this stuff out by adding your trusted class with -Xbootclasspath/a: and your untrusted classes with -classpath (this is how the feature was tried out before it was implemented).

JNLPAppletLauncher is an example of how to have trusted-libraries invoke applet code. The applet class loader can be obtained with Thread.currentThread().getContextClassLoader(), and it's just reflection from there. Writing safe trusted library code is tricky. Remember, you can't trust untrusted code.