Querstion about ForkJoinPool / SecurityManager interoperability

Patrick Reinhart patrick at reini.net
Thu Dec 13 13:44:45 UTC 2018


Hi Dough,

Thanks first of all for that quick answer...

On 2018-12-13 14:23, Doug Lea wrote:
> 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.

I do also not have a better solution for that case (at least this saved
my live for now)


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

ok, so then in that regard the main thread is the caller here.

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

In my case it would made sense that the actual active SecurityManager 
would
have been called for permission to set the context class loader (in my 
case
with the Weld initialization the actual context loader would be "null" 
and
after be reset to the one previously returned by the Thread.

This special case could have been handled also by the 
InnocuousForkJoinWorkerThread
could in my opinion be relaxed to accept null or the system classloader 
to be set
using setContextClassLoader() something like this:

public void setContextClassLoader(ClassLoader cl) {
   if (cl == null || ClassLoader.getSystemClassLoader().equals(cl)) {
     return;
   }
   throw new SecurityException("setContextClassLoader");
}

-Patrick


More information about the core-libs-dev mailing list