RFR: 8155775: Re-examine naming of privileged methods to access System properties

Sean Mullan sean.mullan at oracle.com
Mon May 2 14:15:29 UTC 2016


This looks good. Just a couple of comments:

* src/java.base/share/classes/java/util/TimeZone.java

698         props.setProperty("user.timezone", id);

This will only change the local copy of the property. I think you want 
to keep the original code which does a System.setProperty.

* src/java.base/share/classes/jdk/Version.java

This is not an issue in your changes, but the current javadoc for 
Version.current() says:

  266      * @throws  SecurityException
  267      *          If a security manager exists and its {@link
  268      *          SecurityManager#checkPropertyAccess(String)
  269      *          checkPropertyAccess} method does not allow access 
to the
  270      *          system property "java.version"

but this can never occur since the code is wrapping the call to 
System.getProperty("java.version") in doPrivileged, so the caller's 
permissions are never checked.

I think that this is a bug in the javadoc of this method and that it 
should not be specified to throw SecurityException. All code already has 
permission to read "java.version" in the default java.policy file. Can 
you file a followon bug to have this fixed?

Thanks,
Sean

On 05/01/2016 07:35 PM, Claes Redestad wrote:
> Hi,
>
> JDK-8154231 added methods to simplify access to system properties from
> internal code, but after some discussion it's been decided to rename
> these methods and document them to make it abundantly clear that they
> are performing a privileged action and that care needs to be taken to
> tread the input and output accordingly:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8155775/webrev.01
> Bug: https://bugs.openjdk.java.net/browse/JDK-8155775
>
> Thanks!
>
> /Claes



More information about the security-dev mailing list