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

[Roger Riggs]

Hi Sean,

Looks good.

I would quibble with System.java:335-6

"Java virtual machine does  not allow a security manager"

I would say only "a security manager is not allowed to be set dynamically."

There is no need to identify the Java virtual machine.  The VM itself 
has nothing to do with it.
Also remove the same phrase in SecurityManager class javadoc.

Regards, Roger


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180914/b9c88856/attachment.htm>