Hi Claes,
So this security manager is part of a much larger program, (a fork of
Jini / Apache River), I've almost finished the transition from Java 8 to
Java 11...
One change I noticed is permissions granted to the java extension
directory are now granted to every domain in our policy provider as the
java.ext.dirs property is now blank, I also had to grant permissions to
a number of jdk modules, after fixing these, everthing running as
expected, except for a few minor test failures.
Next step will be to test against the EA builds.
On 17/08/2019 7:24 AM, Peter Firmstone wrote:
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.
