Querstion about ForkJoinPool / SecurityManager interoperability
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
Could you explain what you would like to have happen?
More information about the core-libs-dev