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