Thanks Andrew,
I've been thinking about how to do this in a compatible manner.
The Guard.check call checks whether SecurityManager is enabled.
All permission checks in the JDK could be changed to call the
Guard.check method. Unfortunately other permission checks in user code
will be broken, if they don't utilise this method, but often the most
important permissions are those defined in JDK code.
If we modify this method to look for a provider that's outside the
java.* namespace.
Then we have a point in the code where we can do something like
SecurityManager, without requiring SecurityManager.
Next step will be to replace all AccessController and
AccessControlContext uses in JDK code with another class outside the
java.* namespace.
In the first instance, we allow SecurityManager, AccessController and
AccessControlContext to behave in their degraded state, passing all JCK
tests.
But then we can create providers to replace their functionality.
This is my current line of thought, as other classes will remain.
Subject.doAs could be an issue, so would need to consider how to manage
that.
This seems the easiest way.
Then for backward compatibility, we make a tool that rewrites java
bytecode, to replace the calls to AccessController and
AccessControlContext with compatible equivalents outside the java.*
namespace in client code. Then there's the case of removing any
references to SecurityManager and looking for SecurityManager permission
checks and replacing them with Guard.check.
Then we could potentially continue to support this functionality on
later versions of Java without detonation.
Cheers,
Peter.
On 2/06/2021 7:35 pm, Andrew Haley wrote:
On 6/1/21 10:06 AM, Peter Firmstone wrote:
If a vendor were to continue supporting SecurityManager and was
backporting from OpenJDK, if it passes the JCK with SecurityManager
disabled, that's still acceptable right?
Look at the licence agreement in conjunction with the JCK users' guide.
See the definition of “Compatible Licensee Implementation”.
