On 10/2/18 8:34 AM, Sean Mullan wrote:
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second
webrev ready for review for this enhancement:
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/
:
2. After further thought, I took Bernd's suggestion [1] and instead of
adding a new property to disallow the setting of a SecurityManager at
runtime, have added new tokens to the existing "java.security.manager"
system property, named "=disallow", and "=allow" to toggle this
behavior. The "=" is to avoid any potential clashes with custom SM
classes with those names. I think this is a cleaner approach. There
are a couple of new paragraphs in the SecurityManager class
description describing the "java.security.manager" property and how
the new tokens work.
I'm not a fan of using double == which is not obvious to catch the
typo. I think the `==` syntax may not be commonly known either (I
suspect it's seldom for a user to override java.security.policy rather
than augmenting it).
Have you considered using simple token `disallow` and `allow` (or
all-caps)? The possibility of a custom security manager class named
`disallow` and `allow` should be low.
Mandy
