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

[David Black]

On 14 September 2018 at 15:22, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 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).


As an another data point, we are using a (custom) security manager to
restrict access to certain cloud environment metadata resources.


-- 
David Black / Security Engineer.