Hello Alan,
Yes, we are aware of those issues.
I mean documenting that system Permission classes should be loaded
before setting a custom SecurityManager, accessing the file system is
important, so if you haven't loaded the necessary classes before setting
a custom SecurityManager, it won't be gracefull... The simplest way of
ensuring classes are loaded is by creating object instances of them.
Perhaps just a note to beware of ensuring necessary classes are loaded
and let developers figure out what they need.
The recursive calls are easy enough to deal with to avoid any stack
overflows using ThreadLocal.
inTrustedCodeRecursiveCall.set(Boolean.TRUE);
try {
delegateContext = AccessController.doPrivileged(
new PrivilegedAction<AccessControlContext>(){
public AccessControlContext run() {
return new
AccessControlContext(finalExecutionContext, dc);
}
}
);
}finally {
inTrustedCodeRecursiveCall.set(Boolean.FALSE); // Must
always happen, no matter what.
}
We've only really been caught out once with some jvm bootstrap changes,
otherwise it's been rock solid.
The other thing we do is once we've got more than three
ProtectionDomains on the stack is execute the ProtectionDomain implies
checks in parallel. Really helps when you're making a lot of network calls.
Cheers,
Peter.
On 16/08/2019 5:04 PM, Alan Bateman wrote:
On 15/08/2019 23:20, Peter Firmstone wrote:
:
The following code is included in the constructor of our
SecurityManager implementation, I suspect we may need to add some
classes to this list, perhaps this is something that needs documenting?
The checkPermission method of custom security manager can run
arbitrary code so recursive initialization, stack overflow, bootstrap
method errors, ... are always hazards. I don't know what documentation
you have in mind but I don't think there is a definite list of classes
that need to be loaded/initialized before the custom security manager
is set because it will come down to the code that it executes in its
checkPermission method.
-Alan.
