Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6988591

Security Exception while accessing cached libraries from Applets / WS Apps

XMLWordPrintable

    • x86
    • windows_xp

      FULL PRODUCT VERSION :
      The problem appeared with
      java version "1.6.0_19"
      java version "1.6.0_20"
      java version "1.6.0_21"
      Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
      Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows XP [Version 5.1.2600]

      A DESCRIPTION OF THE PROBLEM :
      We have two different applets:

      - The so called 'light' applet is using the (old) applet tag to be backwards compatible
      - The so called 'main' applet is using a jnlp file

      Both applets share two common libraries. (Both applets and all libraries are correctly signed with the same official certificate.)

      1.)
      First the 'light' applet is loaded and the applet and two jars are cached. Since there is no way to specify a version attribute the version of the libs is null. (Can be seen in the java cache viewer under ressources)

      2.)
      The 'main' applet is loaded and among others it is loading the (exact) same library which has been loaded by the light applet. However inside the jnlp file it is possible to specify a version attribute thus the library is cached a second time - the only difference is the version attribute.

      => So now the problem appears (not on all system configurations but I didn't yet figure out what's the difference)
      When accessing the page again (which loads both applets sequentially) an error message pops up stating:

      Caused by: java.lang.SecurityException: class "com.example.stuff.SomeClass" does not match trust level of other classes in the same package"

      REMARKS:
      - This problem first appeared in 1.6.0_19
      - In 1.6.0_19 and 1.6.0_20 the error is as stated above. Since 1.6.0_21 we get an NPE (as described in the comments of Bug 6967414)
      - It seems that one of the applet accesses the wrong library and then the exception occurs

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. Two applets - one with and the other without jnlp file (with libs version attributes specified)
      2. Both share a common library
      3. Call the applets (so that the applets and the libs are cached)
      4. Call the applets again

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      No problem calling both applets and no security pop up / exception.
      ACTUAL -
      Pop up with the following message: "java has discovered application components that could indicate a security concern"
      Block <yes <no>

      -> But even if not blocked the applet does not continue

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      java.lang.reflect.InvocationTargetException
      at com.sun.deploy.util.DeployAWTUtil.invokeAndWait(Unknown Source)
      at sun.plugin2.applet.Plugin2Manager.runOnEDT(Unknown Source)
      at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
      at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
      at java.lang.Thread.run(Unknown Source)
      Caused by: java.lang.SecurityException: class "com.example.stuff.SomeClass" does not match trust level of other classes in the same package
      at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
      at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
      at sun.plugin2.applet.JNLP2ClassLoader.findClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.Class.getDeclaredConstructors0(Native Method)
      at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
      at java.lang.Class.getConstructor0(Unknown Source)
      at java.lang.Class.newInstance0(Unknown Source)
      at java.lang.Class.newInstance(Unknown Source)
      at sun.plugin2.applet.Plugin2Manager$12.run(Unknown Source)
      at java.awt.event.InvocationEvent.dispatch(Unknown Source)
      at java.awt.EventQueue.dispatchEvent(Unknown Source)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.run(Unknown Source)
      Ausnahme: java.lang.reflect.InvocationTargetException

      REPRODUCIBILITY :
      This bug can be reproduced often.

      CUSTOMER SUBMITTED WORKAROUND :
      As a workaround we removed the version information in the jnlp file and thus the library was just cached once. Then after some initial testing it appears that both applets do not have a problem.

            herrick Andy Herrick (Inactive)
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: