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.
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?
-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
>>>
>>>
>>>
>>>
>>>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com