Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Thu Oct 4 00:52:16 UTC 2018

Hi, Sean.
One question related to SecurityManager and performance, is it possible 
to provide a special version of AccessController.doPrivileged which will 
be noop if SecurityManager is not present?

On 03/10/2018 13:12, Sean Mullan wrote:
> 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.mullan at oracle.com>
> Organization: Oracle Corporation
> To: security Dev OpenJDK <security-dev at 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

Best regards, Sergey.

More information about the core-libs-dev mailing list