United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6940157 extention jnlp files also now need security->all-permissions to avoid mixed code dialog
JDK-6940157 : extention jnlp files also now need security->all-permissions to avoid mixed code dialog

Details
Type:
Bug
Submit Date:
2010-04-01
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2010-05-28
Component:
deploy
OS:
solaris_8
Sub-Component:
webstart
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u19
Fixed Versions:
6u21 (b05)

Related Reports

Sub Tasks

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

This is the new mixed code security check and is expected behavior
as of 6u19.
                                     
2010-04-08
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.
                                     
2010-05-11
EVALUATION

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



Hardware and Software, Engineered to Work Together