How to handle AccessControlException with ProtectionDomain null

614 views Asked by At

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 AccessControlExceptions, 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 ForkJoinWorkerThreads, 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.

1

There are 1 answers

2
Hans On BEST ANSWER

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 ForkJoinWorkerThreads created by the ForkJoinPool.defaultForkJoinWorkerThreadFactory now (falsely?) get a non-permitting AccessControlContext INNOCUOUS_ACC assigned.