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

[Bernd Eckenfels]

There is another way, by reusing the existing security manager property with a new keyword („default“ is already a well known value) one could implement the stable suppression of the SM without actually needing a new property. It also avoids unclear meaning of denied but specified SM:

java.security.manager=disabled // or „denied“ or „forbidden“ or simply „false“

This would also allow an „ignored“ (setSM does nothing).

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: -1056361920m Auftrag von
Gesendet: Freitag, September 14, 2018 8:23 PM
An: Daniel Fuchs
Cc: security Dev OpenJDK
Betreff: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable



On 9/14/18 4:52 AM, Daniel Fuchs wrote:
> The name "jdk.allowSecurityManager" is actually fine.
>
> I was also confused at first because I believed the
> property, if set to false, would just prevent someone
> to call System::setSecurityManager at runtime, whereas
> it also prevents to set a security manager on the command
> line.
>
> Maybe emphasizing this would remove any confusion.

Yes, I was confused about this too -- I didn't realize that the
jdk.allowSecurityManager property also disallowed setting the security manager
via the java.security.manager property. I thought it just applied to the
System.setSecurityManager() method.

(Well, it turns out that setting the java.security.manager property on the
command line ends up calling System.setSecurityManager(), but this is buried
inside the implementation.)

So yes, the effect of setting jdk.allowSecurityManager needs to be specified
more explicitly.

> I wonder if the VM should fail to start if both
> -Djdk.allowSecurityManager=false and -Djava.security.manager
> are supplied?

Maybe, but I don't know that this is necessary. Again, if it's made clear enough
that the java.security.manager property is IGNORED if
jdk.allowSecurityManager=false, then that's OK with me.

s'marks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180914/8629e261/attachment.htm>