Hi Tom,
Tom Ware wrote:
> Hi Marina,
>
> Are you saying that the access control exception we are getting is
> because of the call to System.getProperties() and that it will be solved
> by the change you suggest in (b)? If so, that sounds like a great
> solution and making the change in TopLinkWeaver and in
> oracle.toplink.essentials.internal.ejb.cmp3.base.PropertiesHandler
> potentially solve the whole bug without the need to add privileged
> blocks around the System.getProperty() lookups.
Yes. This is what I'm saying.
But PropertiesHandler iterates over all properties and looks for anything that
starts with a specified name. Unless we can change that to iterate over
a list of known names instead, I don't think we can switch.
>
> If the above is not what you are saying, I am a little confused. If
> GlassFish is granting us permission to read properties, why are we
> seeing the initial exception?
PropertiesHandler$Prop.getPrefixValuesFromMap.
thanks,
-marina
>
> -Tom
>
> Marina Vatkina wrote:
>
>> Hi Tom,
>>
>> This is what I learned so far:
>>
>> 1) (From Java SE expert) default permissions granted by the
>> <java-home>/lib/security/java.policy in Sun implementation.
>> In 5.0u7, they were:
>>
>> permission java.util.PropertyPermission
>>
>> "java.version", "read";
>> "java.vendor", "read";
>> "java.vendor.url", "read";
>> "java.class.version", "read";
>> "os.name", "read";
>> "os.version", "read";
>> "os.arch", "read";
>> "file.separator", "read";
>> "path.separator", "read";
>> "line.separator", "read";
>>
>> "java.specification.version", "read";
>> "java.specification.vendor", "read";
>> "java.specification.name", "read";
>>
>> "java.vm.specification.version", "read";
>> "java.vm.specification.vendor","read";
>> "java.vm.specification.name", "read";
>> "java.vm.version", "read";
>> "java.vm.vendor", "read";
>> "java.vm.name", "read";
>>
>> 2) (From GF security expert) In GF we do grant all code the ability to
>> read all System properties (which arguably carries with it some
>> Security liabilities).
>>
>> Questions:
>>
>> a). Do you still want to have doPrivileged block around all of them?
>> Note that some are in antlr code and might require such block in the
>> parser instead.
>>
>> b). Do you see a problem if I replace in TopLinkWeaver
>> System.getProperties().getProperty(...) with System.getProperty(...)?
>>
>> thanks,
>> -marina
>>
>>
>> Tom Ware wrote:
>>
>>
>>> I am ok with doing option a.
>>>
>>> A couple of things you should know...
>>>
>>> There is unprivileged access to the following properties in other
>>> areas of TopLink. Oracle AS solves this issue by granting permission
>>> to it's applications to access those properties.
>>>
>>> - line.separator
>>> - java.version
>>> - user.dir
>>> - file.separator
>>> - path.separator
>>> - java.io.tmpdir
>>>
>>> -Tom
>>>
>>> Marina Vatkina wrote:
>>>
>>>
>>>
>>>> Hi Tom,
>>>>
>>>> Do you expect the fix for this issue by a) adding a doPrivileged
>>>> block around
>>>> System.getProperties() or b) by adding a new class and corresponding
>>>> methods
>>>> in TopLink oracle/toplink/essentials/internal/security package?
>>>>
>>>> It's easy to do a), but I have a problem with option b) - it allows
>>>> unauthorized
>>>> access to a malicious code: the jars under GF have all permissions,
>>>> plus a
>>>> public method with doPrivileged block will block further security
>>>> access
>>>> validation.
>>>>
>>>> Do you see a problem if I do a) and file a separate bug for b)?
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>>
>>>>
>>>>
>
>