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