Querstion about ForkJoinPool / SecurityManager interoperability

Doug Lea dl at cs.oswego.edu
Thu Dec 13 13:23:37 UTC 2018

On 12/13/18 7:36 AM, Patrick Reinhart wrote:

> Now the special case of using those special threads with no permission
> are only created when the ForkJoinPool is initialized with a security
> manager installed at this point of time. If the security manager will be
> installed later, it has not impact what so ever (this is my actual
> work-around the problem for now)

Dynamically installing a security manager encounters races that at best
need a lot of care to manage. This is an issue in several contexts (not
just thread pools). Sorry that I don't know of a general solution.

> 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)

The rationale is that parallel workers should not have more permissions
than callers, but possibly fewer.

> Why is this done this way and the change of the context class loader or
> uncaught exception handler not checked by the actual security manager
> instead?

Could you explain what you would like to have happen?


More information about the core-libs-dev mailing list