Fwd: new hurdle for applications which programatically install a SecurityManager

[Rick Hillegas]

Thanks for the quick response and for the pointer to 
https://bugs.openjdk.java.net/browse/JDK-8203316

The change in the default value of java.security.manager prevents Derby 
from installing a SecurityManager when the user forgets to. This 
increases Derby's attack surface, significantly in my opinion.

On 11/18/21 11:21 AM, Sean Mullan wrote:
>
>
> On 11/18/21 1:22 PM, Rick Hillegas wrote:
>> Here's the output I get when I run that program against 18-ea+23-1525
>> WITHOUT setting java.security.manager on the boot command line:
>>
>> Exception in thread "main" java.lang.UnsupportedOperationException: The
>> Security Manager is deprecated and will be removed in a future release
>>       at java.base/java.lang.System.setSecurityManager(System.java:411)
>>       at DERBY_7126_B.main(DERBY_7126_B.java:34)
>>
>> Here's the output I get when I run that program against 18-ea+23-1525
>> but do set java.security.manager on the boot command line:
>>
>> WARNING: A terminally deprecated method in java.lang.System has been 
>> called
>> WARNING: System::setSecurityManager has been called by DERBY_7126_B
>> (file:/Users/rhillegas/src/)
>> WARNING: Please consider reporting this to the maintainers of 
>> DERBY_7126_B
>> WARNING: System::setSecurityManager will be removed in a future release
>>
>> Is this asymmetry in the handling of this new system property
>> deliberate?
>
> Yes. The system property is read early (and never again) in VM init 
> phase 3.
>
>> If so, what is the motivation for this asymmetry? 
>
> One of the motivations is to improve the performance of applications 
> that do not use the Security Manager. These applications ideally 
> should not have to incur the cost of supporting a SecurityManager if 
> it is not used. By reading the system property early, the code for 
> loading and checking the security field can be removed. More details 
> are in the CSR for this change that initially went into JDK 12: 
> https://bugs.openjdk.java.net/browse/JDK-8203316
>
>> If not,
>> can the new property be made to operate like the other SecurityManager
>> properties, that is, can the JDK be amended so that
>> java.security.manager can be set programatically?
>
> AFAIK, the "java.security.manager" system property has always been 
> read early before the main application is launched. Also, a change 
> like that would negate the performance benefits described above.
>
> --Sean
>