Unlike the Policy Provider, the SecurityManager doesn't need to be
loaded by the extension ClassLoader.
Anyway while designing the new SecurityManager, I've added support for
net.jini.security.SecurityContext and overridden the
SecurityManager.getContext() method, to return a SecurityContext, which
encapsulates an AccessControlContext as well as other information that
defines the current context.
SecurityContext is an interface used by Policy providers and
SecurityManager's to implement custom context's, for example
AggregatePolicyProvider implements it to preserve the ContextClassLoader
when taking a snapshot of the context.
All permission checks use this context.
This would include adding net.jini.security.Security to that jar file as
well and removing it from jsk-platform.jar
It's important to minimise code that goes into this jar file, because it
will be called by privileged system code like
sun.security.provider.PolicyFile, when determining permissions, so to
avoid creating an infinite circular call stack, the SecurityManager has
to remove it's own ProtectionDomain from the stack. This code must be
trusted, so it's important to minimise it's size.
Thoughts?
Peter.
