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
