2

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.

Hans
  • 2,419
  • 2
  • 30
  • 37

1 Answers1

1

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.

Hans
  • 2,419
  • 2
  • 30
  • 37
  • 1
    The linked bug report is about *subclasses* of `ForkJoinWorkerThread`. Are you subclassing it? As otherwise, giving them no permissions is precisely the point of JDK-8237117. – Holger Jul 27 '20 at 15:39
  • Thanks for pointing that out - I had linked the wrong bug (there are a few related ones there); I have updated the answer. Which parts of that change were intended (and which were regressions) I will leave for the Java people to decide. – Hans Jul 28 '20 at 06:39