Querstion about ForkJoinPool / SecurityManager interoperability

Martin Buchholz martinrb at google.com
Fri Dec 14 15:11:52 UTC 2018

On Thu, Dec 13, 2018 at 4:37 AM Patrick Reinhart <patrick at reini.net> wrote:

> Even if the security manager is enabled before the initialize of the
> ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread
> instances (sometimes it picks the main thread instead, that has not the
> restrictions, what I think should not be the case and is a potential
> security leak too)

Looking again at testCommonPoolThreadContextClassLoader, we had once
noticed that a common pool task might escape into a caller thread, but as
usual, we then forgot about it.

  97         // Ensure runInCommonPool is truly running in the common pool,
  98         // by giving this thread no opportunity to "help" on get().

 And this might indeed be a security problem that should be fixed.

More information about the core-libs-dev mailing list