RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
David Lloyd
david.lloyd at redhat.com
Fri Sep 14 13:28:09 UTC 2018
On Fri, Sep 14, 2018 at 8:22 AM 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).
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. :)
--
- DML
More information about the security-dev
mailing list