Thanks Claes,
I'll run some tests :)
Cheers,
Peter.
On 16/08/2019 9:14 PM, Claes Redestad wrote:
Hi Peter,
by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things stay neutral w.r.t.
Permission initialization order when using any SecurityManager. It's not
perfectly identical, so while unlikely, there's a theoretical
possibility some implementation scenario not covered by our regression
tests might run into issues. Any help testing custom implementation on
coming EA builds would be greatly appreciated!
One thing we could do on the JDK end to reduce fragility somewhat in
this area is to provoke initialization of
sun.security.util.SecurityConstants before installing the first SM.
/Claes
On 2019-08-16 12:40, Peter Firmstone wrote:
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.