On 4/29/21 1:37 AM, Peter Firmstone wrote:
Which version of Java is this planned for? Will the last version
supporting the security manager be a long term support version, eg back
ports of security patches and TLS technologies?
The JEP has not been targeted to a release yet, but the Security Manager
(SM) will continue to be supported in current/previous releases, and its
full functionality will be supported in the release it is targeted to
(if approved). So, if it goes in 17, the SM will be deprecated but it
will still be fully functional, although you may have to enable it on
the command-line with the system property
"-Djava.security.manager=allow". See the warnings section in the JEP for
more details [1].
Subsequent releases may degrade the Security Manager APIs such that it
is not fully supported but the intent is to try to preserve
compatibility such that libraries that are coded with doPrivileged
blocks continue to work without re-compilation for a number of releases
before the APIs are actually removed. See the 2nd bullet of [2] in the JEP.
We have our own security manager implementation and policy provider
implementations. Both of these are high performance and non-blocking
and we are able to dynamically grant and revoke some permissions. While
I acknowledge the Java policy implementation has a significant
performance impact, due to blocking permission checks, ours is less than
1%. Our software doesn't share PermissionCollection instances among
threads, or even have a Permissions cache, PermissionCollection's are
generated for each permission check and discarded for garbage
collection, the Permission object themselves are cached (after
initialization and safe publication), as are the results of repeated
permission checks. We also have our own Permission implementations.
Yes, you and I had discussions about this several years ago and I
believe I asked if you would be willing to donate these performance
improvements. I can't remember but I think you had interest in doing
that but couldn't make it happen for some reason.
We have tools that generate policy files with least privilege, although
we will manually alter them with wildcards, for network connections for
instance.
In our software, dynamic permissions are granted after authentication of
TLS connections.
It is too early for me to tell if there are suitable replacement
technologies available. I can understand the motivation for reducing
Java's software development burden, but I think this version of Java
might be the last for us, it would certainly be good if a long term
support version was available, perhaps indefinitely lol.
Well, indefinitely is a strong word :), and this is really based on
vendor's support models, but I think it is safe to say the SM will be
supported for at least 5-10 years into the future on 17 or previous JDK
releases.
Thanks,
Sean
[1] https://openjdk.java.net/jeps/411#Issue-warnings
[2] https://openjdk.java.net/jeps/411#Risks-and-Assumptions
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
On 16/04/2021 4:05 am, mark.reinh...@oracle.com wrote:
https://openjdk.java.net/jeps/411
Summary: Deprecate the Security Manager for removal in a future
release. The Security Manager dates from Java 1.0. It has not been the
primary means of securing client-side Java code for many years, and it
has rarely been used to secure server-side code. To move Java forward,
we intend to deprecate the Security Manager for removal in concert
with
the legacy Applet API (JEP 398).
- Mark
