For those of you that are not also subscribed to security-dev, this is
mostly FYI, as the review is winding down, but if you have any comments,
let me know.
This change will add new token options ("allow" and "disallow") to the
java.security.manager system property. The "disallow" option is intended
to provide a potential performance boost for applications that don't
enable a SecurityManager, as there is a cost associated with allowing a
SecurityManager to enabled at runtime, even if it is never enabled. The
CSR provides a good summary of the issue and spec changes:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
-------- Forwarded Message --------
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's
security manager immutable
Date: Tue, 2 Oct 2018 11:34:09 -0400
From: Sean Mullan <sean.mul...@oracle.com>
Organization: Oracle Corporation
To: security Dev OpenJDK <security-...@openjdk.java.net>
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second webrev
ready for review for this enhancement:
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/
The main changes since the initial revision are:
1. System.setSecurityManager is no longer deprecated. This type of
change clearly needs more discussion and is not an essential part of
this RFE.
2. After further thought, I took Bernd's suggestion [1] and instead of
adding a new property to disallow the setting of a SecurityManager at
runtime, have added new tokens to the existing "java.security.manager"
system property, named "=disallow", and "=allow" to toggle this
behavior. The "=" is to avoid any potential clashes with custom SM
classes with those names. I think this is a cleaner approach. There are
a couple of new paragraphs in the SecurityManager class description
describing the "java.security.manager" property and how the new tokens work.
3. I also added a comment that Bernd had requested [2] on why
System.setSecurityManager calls checkPackageAccess("java.lang").
Also, the CSR has been updated:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html
On 9/13/18 4:02 PM, Sean Mullan wrote:
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager to
be set at run-time. However, because of this mutability, it incurs a
performance overhead even for applications that never call it and do not
enable a SecurityManager dynamically, which is probably the majority of
applications.
For example, there are lots of "SecurityManager sm =
System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If
it was known that a SecurityManager could never be set at run-time,
these checks could be optimized using constant-folding.
There are essentially two main parts to this change:
1. Deprecation of System.securityManager()
Going forward, we want to discourage applications from calling
System.setSecurityManager(). Instead they should enable a
SecurityManager using the java.security.manager system property on the
command-line.
2. A new JDK-specific system property to disallow the setting of the
security manager at run-time: jdk.allowSecurityManager
If set to false, it allows the run-time to optimize the code and improve
performance when it is known that an application will never run with a
SecurityManager. To support this behavior, the
System.setSecurityManager() API has been updated such that it can throw
an UnsupportedOperationException if it does not allow a security manager
to be set dynamically.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
JBS: https://bugs.openjdk.java.net/browse/JDK-8191053
(I will likely also send this to core-libs for additional review later)
--Sean
