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
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
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.