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

extention jnlp files also now need security->all-permissions to avoid mixed code dialog

    Details

    • Subcomponent:
    • Introduced In Version:
    • Resolved In Build:
      b05
    • CPU:
      x86
    • OS:
      solaris_8
    • Verification:
      Verified

      Description

      FULL PRODUCT VERSION :
      java version "1.6.0_19"
      Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
      Java HotSpot(TM) 64-Bit Server VM (build 16.2-b04, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows [Version 6.1.7600]

      A DESCRIPTION OF THE PROBLEM :
      We had this main.jnlp file:

      <?xml version="1.0" encoding="utf-8"?>
      <jnlp spec="1.0+"
            codebase="http://localhost:8080"
            href="test.jnlp">
         <information>
            <title>Servoy Client - servoy_client</title>
            <vendor>Servoy</vendor>
            <homepage href="http://www.servoy.com/"/>
            <description>Database client</description>
            <icon href="/lib/images/servoy_client_icon.gif" />
            <icon kind="splash" href="/lib/splashclient.gif" width="64" height="64"/>
         </information>
         <resources>
            <j2se version="1.5+" />
            <j2se version="1.6+" />
            <jar href="main.jar" download="eager" version="8"/>
            <extension name="utility" href="utility.jnlp"/>
         </resources>
         <application-desc main-class="com.first.jar.Main">
      </application-desc>
      <security>
          <all-permissions/>
      </security>
      </jnlp>

      then in the extention jnlp:

      <?xml version="1.0" encoding="utf-8"?>
      <jnlp spec="1.0+"
            codebase="http://localhost:8080"
            href="utility.jnlp">
         <information>
            <title>Servoy Client - servoy_client</title>
            <vendor>Servoy</vendor>
            <homepage href="http://www.servoy.com/"/>
            <description>Database client</description>
         </information>
         <resources>
            <jar href="utility.jar" download="eager" version="8"/>
            <jar href="utility2.jar" download="eager" version="2"/>
         </resources>
         <component-desc/>
      </jnlp>


      we dont specify the security,

      Before update 19 of java 6 this was not a problem, even the 2 utility classes didnt need to be signed. But now we somehow have to sign it.
      But even if we sign the 2 jars now. We still have to also add

      <security>
          <all-permissions/>
      </security>

      to all our extention jars.

      This update 19 breaks so many things for our product this way.

      One thing is that we have a product that can be extended by plugins. So those extensions are not provided by us but by 3th party plugin developers. Now all those developers need to sign there code and make sure that all there jnlp files will generate that security tag also, even if they dont need anything os specific.. Why is the security not inherited from the main jnlp file?


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      try the above jnlp files including the use of extentions.


      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      I get a message that signed and unsiged code is being tried to run (which is not true! and when press yes in that dialog that i want to block it i get this:

      ava.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://localhost:8080/utility.jar
      at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
      at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
      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 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)
      at com.first.jar.Main.main(Main.java:12)
      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)


      REPRODUCIBILITY :
      This bug can be reproduced always.

      SUPPORT :
      YES

      Release Regression From : 6u19
      The above release value was the last known release where this
      bug was not reproducible. Since then there has been a regression.

        Attachments

          Activity

            People

            • Assignee:
              jdn Jeffrey Nisewanger (Inactive)
              Reporter:
              ndcosta Nelson Dcosta (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: