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

Alan Bateman Alan.Bateman at oracle.com
Fri Sep 14 13:22:25 UTC 2018


On 14/09/2018 13:46, David Lloyd wrote:
> :
>> 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.
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).

-Alan



More information about the security-dev mailing list