The Open JDK regards the Java Security Manager as a large, brittle piece
of code whose further maintenance costs too much. In some imminent
release, the JVM will remove the Security Manager. See
https://openjdk.java.net/jeps/411,
https://issues.apache.org/jira/browse/DERBY-7110, and
https://issues.apache.org/jira/browse/DERBY-7126.
For Derby, the Security Manager provides important defenses against the
mis-use of the following security-sensitive operations:
o Reading and setting of system properties.
o Creation of class loaders.
o File access
o Network access
o De-registration of JDBC drivers
In preparation for the 10.16.1 release, I asked the Open JDK security
team for advice. How should Derby users protect these operations on a
future JVM which no longer includes the Security Manager? I asked for
guidance in a security-...@openjdk.java.net email thread titled
"protecting security-sensitive operations on multi-tenant servers." The
security team said:
1) The Security Manager was the wrong solution to this problem.
2) The better, modern solution would be to isolate your application
inside an operating system container.
This seems to be the situation: In some future release, we will need to
remove all references to the Security Manager and we will need to tell
users to containerize their applications.
I'm happy to rototill away references to the Security Manager and update
the Security Guide accordingly. I estimate that this will take about a
month. My preference would be to delay the 10.16.1 release until this is
done. However, there may be some reason to produce a 10.16.1 release
first (the last release which uses the Security Manager) and introduce
this change in 10.17.1.
What are your thoughts?
-Rick
