From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Wed, 30 Aug 2006 09:37:55 -0700

Hi Tom,

Yes. That's the plan :).

thanks,
-marina

Tom Ware wrote:
> Hi Marina,
>
> Thanks for the correction.
>
> Is your current plan to make the change suggested in (b) and also to
> wrap the call to getProperties() in
> PropertiesHandler$Prop.getPrefixValuesFromMap() in a Privileged block?
> If so, that solution sounds fine to me.
>
> -Tom
>
> Marina Vatkina wrote:
>
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>