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

[Sean Mullan]

On 9/14/18 9:28 AM, David Lloyd wrote:
>> The security manager is legacy these days and I think we need to figure
>> out a plan how to deprecate and eventually bury it. I have no idea how
>> many releases or years that might take but the proposal here is a
>> profitable first step. It's easy to imagine follow on steps where the
>> default changes to not support the security manager without some opt-in.
>> Yes, this will be disruptive for a number of usages but there is lots of
>> time to look for solutions to the issues that people are using the
>> security manager for today - for example we've seen several cases where
>> people set a security manager because they lack hooks to prevent plugins
>> from doing things (plugins or tests calling System.exit comes up
>> periodically for example).
> I can say that this explanation would be more palatable by far if the
> security manager as a whole could be deprecated all at once.  I for
> one would certainly be happy to remove support for it in the software
> that I maintain (it's a considerable amount of code and other
> gymnastics to be sure).  However, I'm not sure that our users and
> customers will be so easily convinced.  My understanding is that there
> are plenty of corporate and perhaps government security standards that
> dictate security manager usage.
> 
> If the security manager itself is not yet to be deprecated, then I
> have a much harder time accepting this argument.  It's not really a
> stepping stone in any practical sense, at least not from our
> perspective, unless that step is "break JBoss first, and then break
> everyone else later"; to be fair though I'm approximately 200% more
> cynical in the morning.:)

Right now we are taking a long look at the Security Manager and what its 
future path should be. We started this initiative back in February with 
a survey [1] to better understand how people use the Security Manager 
(outside of applets and Web Start applications) and what challenges and 
issues they had in using it.

In JDK 10 we removed some old methods that were not useful anymore [2].

This particular issue focuses on improving the performance of 
applications that never use the Security Manager. It is the first of 
potentially several enhancements in that area.

As for the future of the Security Manager, deprecating and eventually 
removing it is one potential option; but there are other options we are 
looking at such as simplifying it. What we really don't want to do is 
continue with what we are doing today and keeping it going for what is 
probably a small percentage of users. And we also don't have the 
resources to enhance it to address everyone's needs. At the end of the 
day it takes a lot of effort to simply maintain the JDK code to run 
properly and securely under a Security Manager.

With that said, I encourage everyone to have an open mind going forward 
as we request your input on different paths we may take. And keep 
sending the comments. We need more use cases and data.

Thanks,
Sean

[1] https://www.surveymonkey.com/results/SM-PSJ6ZNMZ8/
[2] https://bugs.openjdk.java.net/browse/JDK-8186535