JDK-8273124 : Change of behavior after JDK-8237117: Better ForkJoinPool behavior - JDK 11
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 11,18
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2021-08-30
  • Updated: 2021-08-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8249846 - Change of behavior after JDK-8237117: Better ForkJoinPool behavior
Description
A DESCRIPTION OF THE PROBLEM :
Behavior of ForkJoinWorkerThread created by defaultForkJoinWorkerThreadFactory have changed after JDK-8237117.

AccessControlContext of the thread is set to the innocuousAcc with no permissions. Previous behavior was to inherit ACC from the thread that created ForkJoinPool. 

The same issue occured in JDK 8, was reported and solved in https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8249846.
The fix(which can be found here https://github.com/openjdk/jdk8u/commit/49cfccbfe5a1cdee4ba77b4dbda69f420a84deac ) wasn't however applied to JDK 11.

REGRESSION : Last worked in version 8u301

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The approach is identical as in referenced above 
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8249846.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
AccessControlContext of ForkJoinWorkerThread should be inherited from the thread that created it.
ACTUAL -
AccessControlContext of ForkJoinWorkerThread is set to innocuousAcc with no permissions.

FREQUENCY : always
Comments
This test is a good example on how difficult it is to develop code that works with the security manager architecture. The test is missing a call to AccessController.doPrivileged so it only works if callers of the compute method and the code in the compute method have the required permissions (FilePermission in this case). Defense-in-depth changes in release JDK releases means that the caller frames only limited privileges.
30-08-2021
The observations on Windows 10: JDK 8: Passed. JDK 11ea+1: Failed, AccessControlException: access denied JDK 18ea+1: Failed.
30-08-2021