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
