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 security-dev
mailing list