Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater

[Martin Buchholz]

On Thu, Apr 15, 2010 at 19:04, David Holmes <David.Holmes at oracle.com> wrote:
> Martin Buchholz said the following on 04/16/10 11:38:
>>
>> On Thu, Apr 15, 2010 at 17:49, David Holmes <David.Holmes at oracle.com>
>> wrote:
>>>
>>> If this proceeds I think you need to include AtomicReferenceFieldUpdater
>>> in
>>> this as well.
>>
>> Agreed.
>>
>> I may have created some confusion because the test in my webrev
>> did not actually demonstrate the problem.
>> I have since fixed that.
>>
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Atomic-security/test/java/util/concurrent/atomic/AccessControl.java.html
>
> Aside: you forgot to call pass().

Not strictly necessary, since the test fails if and only if it throws.

>> The problem happens even for well-behaved classes that only
>> use atomic updaters to update their own fields.
>
> I don't think installing a security manager that permits nothing and then
> getting a SecurityException is a good indicator of a problem.
>
>> Now, they
>> could work around the problem by creating their atomic updater
>> inside a doPrivileged, but probably we intend for them not to
>> have to do that.
>
> That won't work. The doPrivileged doesn't give them any additional
> permissions in their code, so it has no affect.

That's not my understanding.  doPrivileged is useful whenever you
want to perform an operation with permissions checked only on the
current stack frame, and not on any other code executing up the stack.

Martin

 doPrivileged is only useful
> for bootstrap classes to have operations checked using the bootstrap class's
> permissions rather than the application class (that's a loose statement but
> suffices).
>
> To answer my own question I think the ReflectUtils checks act the same way
> that getDeclaredField() inside a doPrivileged would act. To that end perhaps
> this suggested change is "correct". Further it seems to me that the real
> security check needs to be done when the updater is applied, not when it is
> created.
>
> But I can't help but wonder what purpose this security check is serving, and
> whether circumventing it is the right thing to do. But I'll let the security
> folk chime in on that.
>
> Thanks,
> David