On 14 September 2018 at 15:22, Alan Bateman <alan.bate...@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.
