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

[Mandy Chung]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181002/6e0d0298/attachment.htm>