In a somewhat old and complex Swing application, we have a custom security manager and policy apparently designed to allow everything:
/*
* allow everything ...
*/
grant codeBase "file:${{java.ext.dirs}}/*" {
permission java.security.AllPermission;
};
grant {
permission java.security.AllPermission;
};
grant codeBase "file:${thecompany.codebase}/-"{
permission java.security.AllPermission;
};
${thecompany.codebase}
is set as a system property and appears to be read correctly. Up to (including) Zulu Java 8 build 252, this works as desired: The GUI starts without apparent issues.
However, when I switch to Zulu Java 8 build 262 (or Oracle 261), I get hundreds of AccessControlException
s, e.g.:
access:
access denied ("java.lang.RuntimePermission" "getProtectionDomain")
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1336)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:462)
at java.security.AccessController.checkPermission(AccessController.java:886)
...
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:171)
All of these errors seem to originate in ForkJoinWorkerThread
s, and the "access" debug outputs for the failures all show the same strange "null" ProtectionDomain
:
access:
domain that failed ProtectionDomain null
null
<no principals>
null
I do not see any ProtectionDomain null
in the "access" debug log when using the JDK build 252.
Reading through the Oracle release notes and bug fixes for update 261, I see a lot of security-related issues, but none strike me as being directly related.
So, under what circumstances (if any) is a ProtectionDomain null
expected, and how does one grant it permissions?
Any idea how to debug this further is welcome.
This has turned out to be a consequence of a change in behaviour in the JDK 261 update: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8249846
The underlying reason is that
ForkJoinWorkerThread
s created by theForkJoinPool.defaultForkJoinWorkerThreadFactory
now (falsely?) get a non-permittingAccessControlContext INNOCUOUS_ACC
assigned.