checkShutdownAccess

[Scott Dixon-2]

I'm working on a system where there is a security manager in place that denies the "modifyThread" permission globally but allows it for the thread group my application runs within. When I use a ThreadPoolExecutor service from 3.1 I get an a security exception:

java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:278)
    at java.security.AccessController.checkPermission(AccessController.java:466)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:537)
    at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:655)
    at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:1330)

The documentation in the source says:

     * Permission required for callers of shutdown and shutdownNow.
     * We additionally require (see checkShutdownAccess) that callers
     * have permission to actually interrupt threads in the worker set
     * (as governed by Thread.interrupt, which relies on
     * ThreadGroup.checkAccess, which in turn relies on
     * SecurityManager.checkAccess). Shutdowns are attempted only if
     * these checks pass.

Since I do have permission to shutdown the threads that are in the threadpool (they are all taken from my application's threadgroup) why does the first check need to occur? In my case it is a false positive and if you have permission to shutdown the worker threads I'm not sure why one would need permission to shutdown any given thread on the system? Am I missing something?

Thanks for the input.

cheers,
-scott

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[David Holmes-6]

Scott,

Here's my summary on this from early 2006. Sorry that it won't help solve your problem. The basic problem is that the security architecture is too coarse when it comes to thread permissions and we had to compromise on the side of being more strict than ideally necessary.

David Holmes
-------------

Here's my summary of the jsr-166 history on the security policy with
regards to shutting down an executor.

We needed to be clear that shutdown might fail because the client
performing the shutdown did not have the right permission(s). This arose
from the context of using Executor implementations in J2EE environments.

Initially we thought perhaps an explicit new permission type was needed,
but this would not have helped because shutdown may involve interrupting
threads and Thread.interrupt has its own security requirements. We
couldn't see a way to ensure that "shutdown" permission implied
modifyThread permission or would allow checkAccess to pass for all the
threads.

So we decided to simply tie shutdown permission to the modifyThread
permission needed to perform a Thread.interrupt. This was far from ideal
as depending on how the executors ThreadFactory produced threads, and
the configured security manager, a client might have permission to
interrupt some threads and not others. Given there was no way to account
for all the possible permutations of behaviour we decided to work on the
premise that you at least had to have modifyThread permission to do a
shutdown.

So it was initially proposed that we simply perform for each worker
thread t SecurityManager.checkAccess(t) if there is a security manager
installed.

However, the default implementation of java.lang.SecurityManager only
actually calls checkPermission if the thread concerned is part of the
"rootGroup". As we were anticipating usage contexts where the threads
most definitely would not be part of the root group, this would mean
that the default SecurityManager would actually provide ZERO security
and anyone could shutdown the executor. There was also no guarantee that
a custom security manager would actually respect the modifyThread
permission anyway when implementing checkAccess.

So the decision was made to check for a SecurityManager and if it was
found to use that as an indication that security checks needed to be
made but to perform a direct checkPermission with the AccessController
to see if you had the modifyThread permission. We additionally call the
security manager's checkAccess method for each thread to be interrupted,
just in case we don't also have that permission (because a custom
security manager might be stricter than the default security manager).

This led to the documented security policy:

@throws SecurityException - if a security manager exists and shutting
down this ExecutorService may manipulate threads that the caller is not
permitted to modify because it does not hold
RuntimePermission("modifyThread"), or the security manager's checkAccess
method denies access.

You must have the permission "modifyThread" AND the installed security
manager must let checkAccess succeed. This prevents a security manager
from ignoring the actual defined security policy.

Footnote: the fact that we called the AccessController directly was deemed to be a "bug" and so in JDK6 it was changed to always use the SecurityManager. This effectively loosened security as described above because we now have to trust the SecurityManager again.

-----Original Message-----
From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...]On Behalf Of Scott Dixon
Sent: Wednesday, 26 August 2009 10:55 AM
To: concurrency-interest@...
Subject: [concurrency-interest] checkShutdownAccess


I'm working on a system where there is a security manager in place that denies the "modifyThread" permission globally but allows it for the thread group my application runs within. When I use a ThreadPoolExecutor service from 3.1 I get an a security exception:

java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:278)
    at java.security.AccessController.checkPermission(AccessController.java:466)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:537)
    at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:655)
    at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:1330)

The documentation in the source says:

     * Permission required for callers of shutdown and shutdownNow.
     * We additionally require (see checkShutdownAccess) that callers
     * have permission to actually interrupt threads in the worker set
     * (as governed by Thread.interrupt, which relies on
     * ThreadGroup.checkAccess, which in turn relies on
     * SecurityManager.checkAccess). Shutdowns are attempted only if
     * these checks pass.

Since I do have permission to shutdown the threads that are in the threadpool (they are all taken from my application's threadgroup) why does the first check need to occur? In my case it is a false positive and if you have permission to shutdown the worker threads I'm not sure why one would need permission to shutdown any given thread on the system? Am I missing something?

Thanks for the input.

cheers,
-scott


_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest