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

Martin Buchholz martinrb at google.com
Thu Oct 3 04:11:01 UTC 2013


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.

Alternatively, is there a reasonable way for a security manager to enable
such usages without enabling arbitrary modifyThread?


On Wed, Oct 2, 2013 at 9:03 PM, David Holmes <david.holmes at oracle.com>wrote:

> On 3/10/2013 1:55 PM, Martin Buchholz wrote:
>
>> On Wed, Oct 2, 2013 at 7:13 PM, David Holmes <david.holmes at oracle.com>**
>> wrote:
>>
>>  On 3/10/2013 2:54 AM, Martin Buchholz wrote:
>>>
>>>  On Wed, Oct 2, 2013 at 9:49 AM, Peter Levart <peter.levart at gmail.com>
>>>> wrote:
>>>>
>>>>   Hi Martin,
>>>>
>>>>>
>>>>> If you want to optimize for without-security-manager case
>>>>>
>>>>>
>>>>
>>>> I want to optimize for the case that Thread.interrupt does not throw
>>>> SecurityException
>>>>
>>>>
>>> How is your proposal optimizing that case ???
>>>
>>
>>
>> Instead of doing extra work to avoid a SecurityException, I am assuming a
>> SecurityException is rare, and risk having to throw it twice.
>>
>
> Sorry I'm missing something - what extra work are you avoiding and where?
> The original code just did t.interrupt() now you've added try/catch with a
> second privileged interrupt attempt. I don't see anything being avoided.
> Are you referring to caller code that catches the SecurityException itself
> and somehow retries?
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20131002/d3454c2b/attachment.htm>


More information about the security-dev mailing list