On 3/10/2013 3:02 AM, 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.
We have been tightening the conditions under which interrupts can be
issued, so relaxing them in this way is simply not acceptable.
David
-----
-Doug
Here's a proposed fix for jdk8+:
--- src/main/java/util/concurrent/FutureTask.java15 May 2013 02:39:59
-00001.103
+++ src/main/java/util/concurrent/FutureTask.java2 Oct 2013 16:25:23
-0000
@@ -132,6 +132,12 @@
return state != NEW;
}
+ private static void privilegedInterrupt(Thread t) {
+ java.security.PrivilegedAction<Void> doInterrupt =
+ () -> { t.interrupt(); return null; };
+ java.security.AccessController.doPrivileged(doInterrupt);
+ }
+
public boolean cancel(boolean mayInterruptIfRunning) {
if (!(state == NEW &&
UNSAFE.compareAndSwapInt(this, stateOffset, NEW,
@@ -142,7 +148,11 @@
try {
Thread t = runner;
if (t != null)
- t.interrupt();
+ try {
+ t.interrupt();
+ } catch (SecurityException e) {
+ privilegedInterrupt(t);
+ }
} finally { // final state
UNSAFE.putOrderedInt(this, stateOffset,
INTERRUPTED);
}
_______________________________________________
Concurrency-interest mailing list
concurrency-inter...@cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
