JDK-4734410 : JAVAWS is passing the property set in extension installer to main program
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2002-08-21
  • Updated: 2002-12-06
  • Resolved: 2002-11-19
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.
Other
1.4.2 mantisFixed
Description
See comments.

###@###.### 2002-08-20

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08 VERIFIED IN: mantis-beta
31-08-2004

SUGGESTED FIX Basically, in the old method of setting properties from the jnlp file, we would Construct the AppPolicy with all the properties from the jnlp file and all it's extensions. Then on the first CodeSource loaded, we would set all those properties (if they start with jnlp, javaws, or if the jnlp file for that CodeSource requested all-permissions, and we are granting). The problem is, that if an extension has all-permissions, and the main jnlp does not, we would try (and fail) to set the property when we loaded the first jar from the main jnlp file. With this change we only load the properties from the jnlp file associated with the CodeSource being loaded, and they will only work according to that CodeSource's permissions. This does not mean that a property set in an extension will not be set for the main program. There is only one VM running, and only one set of system properties. However, a property will not be set, or attempt to be set, until a CodeSource from a jar in the jnlp file containing that property is loaded and verified. ###@###.### 2002-10-16
16-10-2002

EVALUATION There are two problems here - one should be an ref to the spec: 1.) Scope of properties listed in extensions is not clear in spec. (The jnlp spec says component-extensions cannot have a j2se element, this should also apply to installer-extensions. The spec does not say anything about property settings in extensions, the code allows it, but since we know restrict properties to start with javaws or jnlp if not in trusted env, we get bug 2.) below) The spec should clearly state that all properties are set in the same VM, so will be available to code loaded from either the main jnlp file or any extensions. 2.) when implementing the security fix requiring sandbox restrictions on setting properties in jnlp files. It was assumed (incorrectly) that all the properties could be set while loading the main jar file of the application, in cases like this we are no longer in a security context that would allow this. I am going to split this into 2 bugs, where 1.) above will be a new spec rfe or bug, and this bug will be confined to the 2.) above. ###@###.### 2002-08-21
21-08-2002

WORK AROUND We have work around: 1. set the property name to be jnlp.* or, let the main jnlp file asking full permission. ###@###.### 2002-08-20
20-08-2002