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

[David Black]

On 14 September 2018 at 13:46, David Lloyd <david.lloyd at redhat.com> wrote:
> On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan <sean.mullan at oracle.com> 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.
>
> What kind of performance overhead?

Yes, have you done performance tests to determine what the overhead is
in "standard applications" (the micro-benchmark in
https://bugs.openjdk.java.net/browse/JDK-8191053 might not be
reflective of actual application performance differences).

>
>> 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.
>
> I think they could be optimized using constant-folding either way, if
> something like SwitchPoint were used instead of a plain field; am I
> incorrect in my understanding?  The reason I ask is... (see below)
>
>> There are essentially two main parts to this change:
>>
>> 1. Deprecation of System.s[etS]ecurityManager()
>
> We (JBoss) use this method to configure some things at run time (like
> customizing the Policy) before installing our security manager, so
> this would be not so great for us.

We also use it. This is certainly an interesting change to me because
there are valid use cases for 'later' enforcing / bringing up a
security manager. Use cases include, being able to execute / perform
operations prior to setting up a security manager (although arguably
it is possible for a custom security manager to await for a signal /
flag to be set to enter an "enforcing mode" or a different
"initialisation" policy).
I was thinking about if it would be useful to permit dynamically
calling setSecurityManager once.


The following quoted part is from Sean Mullan's initial email (just to
avoid any confusion) ->

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


As an outsider this change, especially when considering the context of
https://bugs.openjdk.java.net/browse/JDK-8200447 felt strange until I
found Alan Bateman's email suggesting that the "security manager is
legacy these day's". On a somewhat related note ... I have been
meaning for some time to bring up the fact that it is harder than it
should be for non-applet applications to make use of a security
manager (this is slightly off-topic I guess ...) - for example:
* cachePolicy being set to forever unless overridden (this is easy to
work around) - there are arguments for and against this but the
behaviour differing between when a security manager is in use and when
one is not can be surprising to some.
* in some breaks usages of ParallelStream because
InnocuousForkJoinWorkerThread can potentially be used (this is fairly
easy to workaround) (also iirc the nio version can also be
problematic).


-- 
David Black / Security Engineer.