JDK-6670470 : JNLP security model prevents redeployment of existing applet content
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-03
  • Updated: 2010-09-08
  • Resolved: 2008-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
6u10 b21Fixed
Related Reports
Relates :  
JDK-6518285 - JNLP specification should support unsigned extensions for unsigned applications
Relates :  
JDK-6670678 - Java Web Start must support a more flexible security model
Description
The JNLP security model is incompatible with the existing applet security model and prevents straightforward redeployment of existing applet content via JNLP. The JNLP security model states among other things that if the main JNLP does not request all permissions via the <security> tag, that JNLP can not pull in resources from multiple hosts. The existing applet security model is at this point very well defined: applets may pull in resources from any host, and permissions are granted based on both the origin of the code and the signing and trust status of that code.

In order to enable straightforward redeployment of existing applet content, it is necessary to remove some of the restrictions artificially imposed by the JNLP specification in the support for JNLP-based applets.
Comments
EVALUATION The JNLP security model is badly broken in the context of applets. It attempts to enforce arbitrary restrictions such as the following: if the main JNLP uses sandbox security, it can not pull in extensions from other hosts. This is a basic feature of old-style applets -- that permissions are granted solely on the origin and trust status of the code -- and it is unacceptable to impose this sort of restriction for JNLP launched applets because it will prevent people from migrating their existing applet deployments to use JNLP as the applet description mechanism. Removed the call to LaunchDownload.checkJNLPSecurity() in the JNLP2Manager. Made AppPolicy.addPermissions() take a boolean argument indicating whether to grant permissions to the class being loaded based on the contents of the JNLP file. For the time being, Java Web Start passes true for this argument and is unchanged. The Java Plug-In's JNLP2ClassLoader passes false, and since it calls super.getPermissions() (which grants permissions based on the origin and trust status of the CodeSource), has the same semantics as old applet deployments. This change makes the Java Plug-In substantially more useful for deployment than Java Web Start, which is also not an acceptable situation. The two technologies must have parity. A very similar bug, 6518285, was filed against Java Web Start over a year ago. A follow-on bug, 6670678, has been filed to make Java Web Start silently degrade gracefully to a similar security model to this one if checkJNLPSecurity() returns false. This bug will be fixed in 6u10 as an implementation bug, while 6518285 is filed against the JNLP specification and can only be fixed in 7.
05-03-2008
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6670470.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6670470
05-03-2008