CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b08

VERIFIED IN:
mantis-beta


                                     

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
                                     

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
                                     

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