ThreadPoolExecutor.shutdown() and permission

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ThreadPoolExecutor.shutdown() and permission

Remi Forax
In ThreadPoolExecutor.shutdown(), if i have correctly understand the
documentation, the code first checks if permission "modifyThread" is granted
and then for each worker threads checks checkAccess.

Why in order to check permission "modifyThread",
you use AccessController.checkPermission() and not
securityManager.checkPermission() ?

This pattern doesn't seems to match with the security
architecture describes here :
http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-specTOC.fm.html

Rémi Forax




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: ThreadPoolExecutor.shutdown() and permission

David Holmes
Remi,

> In ThreadPoolExecutor.shutdown(), if i have correctly understand the
> documentation, the code first checks if permission "modifyThread"
> is granted and then for each worker threads checks checkAccess.
>
> Why in order to check permission "modifyThread",
> you use AccessController.checkPermission() and not
> securityManager.checkPermission() ?

Only AccessController.checkPermission guarantees that you actually check if
you have the permission. This class can't be modified by the application.

The SecurityManager.checkAccess could do anything it wants even ignoring the
installed security policy.

So to perform shutdown() you have to have the global modifyThread
permission, and for each worker thread the SecurityManager's checkAccess
must succeed.

David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor.shutdown() and permission

Remi Forax
David Holmes wrote:

>Remi,
>
>  
>
>>In ThreadPoolExecutor.shutdown(), if i have correctly understand the
>>documentation, the code first checks if permission "modifyThread"
>>is granted and then for each worker threads checks checkAccess.
>>
>>Why in order to check permission "modifyThread",
>>you use AccessController.checkPermission() and not
>>securityManager.checkPermission() ?
>>    
>>
>
>Only AccessController.checkPermission guarantees that you actually check if
>you have the permission. This class can't be modified by the application.
>
>The SecurityManager.checkAccess could do anything it wants even ignoring the
>installed security policy.
>  
>
Yes i agree with you,  but if the security manager wants to ignore the
policy
it's not the responsibility of shutdown() to care about such detail.

By doing this, shutdown() you break the general security architecture of
Java.
Perhaps for you, this code is more secure but if additionnal security
checks are
implemented by the security manager, these tests are bypassed.
So this code can be considered as less secured.

>So to perform shutdown() you have to have the global modifyThread
>permission, and for each worker thread the SecurityManager's checkAccess
>must succeed.
>  
>
>David Holmes
>  
>
Rémi Forax


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: ThreadPoolExecutor.shutdown() andpermission

David Holmes
> Yes i agree with you,  but if the security manager wants to ignore the
> policy it's not the responsibility of shutdown() to care about such
detail.
>
> By doing this, shutdown() you break the general security architecture of
> Java.

I disagree. The SecurityManager is a remnant of the old security
architecture. The 1.2 architecture says that security is determined by the
installed security policy. If shutdown should be allowed then the correct
permission should be installed. The additional check of the SecurityManager
is to allow for a more restrictive security policy not a less restrictive
one.

That said it does seem that we enforce more security than other core classes
do, even Thread. I thought that Thread used both SecurityManager.checkAccess
and SecurityManager.checkPermission in certain cases, so that the need for
the permission could block access even if checkAccess allowed it. I presumed
that SecurityManager.checkPermission would be final but it is not - which
seems like an oversight to me (otherwise why call checkAccess and
checkPermission?)

The strategy used on shutdown() was approved by the JDK security folk.

Cheers,
David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest