Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
Sean Mullan
sean.mullan at oracle.com
Thu Oct 4 12:50:14 UTC 2018
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
>
>
More information about the core-libs-dev
mailing list