Open pfirmstone opened 1 year ago
Refer to JEP 411 Deprecate the Security Manager for Removal #126
After researching all options, I've come to the conclusion that I will need to maintain a patched version of OpenJDK that retains SecurityManager. This also provides an opportunity to address a number of issues with SecurityManager in OpenJDK, such as updating the default policy provider, and allowing SocketPermission's to be granted to network subnet masks, adding permission checks for Java serialization and deserialization.
In order to maintain compatibility with Java that retains security manager, and one that doesn't, we will need to use reflection to check for the presence of classes in the underlying implementation. This would ordinarily cause recursive permission checks, however we have a strategy for handling that using thread local variables, as per CombinerSecurityManager.
Any assistance will be greatly appreciated.
Is your feature request related to a problem? Please describe. AccessController and AccessControlContext have been deprecated for removal, we need to find a replacement, but need to do so with as little impact to downstream developers as possible.
Describe the solution you'd like net.jini.security.Security has equivalent methods, which encapsulate AccessController and AccessControlContext, so that we may replace the implementation at a later stage. Using a service provider mechanism sounds like a good idea, however this could cause problems with circular threads and permission checks.