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
