JDK-6940157 : extention jnlp files also now need security->all-permissions to avoid mixed code dialog
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u19
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: x86
  • Submitted: 2010-04-01
  • Updated: 2011-02-16
  • Resolved: 2010-05-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u21 b05Fixed
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.

Comments
EVALUATION We will try to address this issue in 6u21 b05.
18-05-2010

EVALUATION This is expected behavior due to mixed code feature implemented in JRE 6u19, without security-all-permissions tag in jnlp file, we will still treat it is unsigned jar file, therefore the mixed code warning dialog box will popup. I will close this bug and we will not fix it.
11-05-2010

EVALUATION This is the new mixed code security check and is expected behavior as of 6u19.
08-04-2010