Querstion about ForkJoinPool / SecurityManager interoperability

Patrick Reinhart patrick at reini.net
Fri Dec 14 22:50:29 UTC 2018

Hi Martin,

In my simplified test, I managed to reproduce the execution in the main
thread, when I did not wait for a start and directly called get()...

as in your test here:

  99         await(taskStarted);


Am 14.12.18 um 16:11 schrieb Martin Buchholz:
> On Thu, Dec 13, 2018 at 4:37 AM Patrick Reinhart <patrick at reini.net
> <mailto: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