FutureTask.cancel(true) should run thread.interrupt within doPrivileged

[David M. Lloyd]

On 10/03/2013 12:12 AM, David Holmes wrote:
> On 3/10/2013 2:11 PM, Martin Buchholz wrote:
>> I was responding to Peter Levart's suggestion of checking for the
>> presence
>> of a security manager before calling doPrivileged.  Which is not an
>> important question now, given that the primary question is whether we
>> should allow future.cancel() to interrupt within a doPrivileged.
>
> Ah I see.
>
>> Alternatively, is there a reasonable way for a security manager to enable
>> such usages without enabling arbitrary modifyThread?
>
> I'm not quite sure what you are asking. Thread permissions are
> notoriously coarse-grained. I thought that was a big mistake when the
> security architecture was updated in 1.2 (?) but here we are a decade
> (or more) later and it seems noone really complained. So be it.
>
> Hypothetically we could define finer-grained permissions to differ
> interrupt from nasty things like stop/suspend. But in practice unless we
> change how we assign that permission then you would still require it and
> wouldn't have it unless using a custom security policy - which would
> allow you to deal with the modifyThread permission too.

Permissions can imply other Permissions.  Any RuntimePermission whose 
action is "modifyThread" could be (in code) modified to imply a host of 
finer-grained ThreadPermission or something like that.

-- 
- DML