[concurrency-interest] FutureTask.cancel(true) should run thread.interrupt within doPrivileged

Martin Buchholz martinrb at google.com
Wed Oct 2 19:31:51 UTC 2013


On Wed, Oct 2, 2013 at 12:18 PM, Tom Hawtin <tom.hawtin at oracle.com> wrote:

> On 02/10/2013 18:02, Doug Lea wrote:
>
>> On 10/02/2013 12:29 PM, Martin Buchholz wrote:
>>
>>> FutureTask.cancel(true) invokes thread.interrupt on the thread (if any)
>>> currently running the task.
>>> This should succeed even if modifyThread permission is denied by the
>>> security
>>> manager.
>>>
>>>
>> We haven't interpreted "should" in this way in the past here or in
>> related contexts, but I don't see are reason not to,  pending any
>> objections by security folks.
>>
>
> Objection. I can straightaway see a way of getting an instance of a JDK-8
> FutureTask with a runner that is not current running the FutureTask.run,
> without so much as needing a race. That would allow an adversary to to
> interrupt a thread in contravention of the security policy.


Interesting - FutureTask is designed to not make that possible - runner is
not exposed, and is supposed to be set only while executing the task.  Do
we have a bug?



More information about the core-libs-dev mailing list