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

[Sean Mullan]

On 10/3/18 8:52 PM, Sergey Bylokhov wrote:
> 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?

Yes, it may be possible, and we have prototyped it. But I didn't want to 
mix it up with this one as it has some different specification 
challenges -- for example, the AccessController APIs can be used 
independently of the SecurityManager. I plan to get back to this one 
soon and hope to have something that can be reviewed a bit later.

Thanks,
Sean

> 
> 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
> 
>