Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater

[David Holmes]

Martin Buchholz said the following on 04/16/10 16:58:
> On Thu, Apr 15, 2010 at 19:04, David Holmes <David.Holmes at oracle.com> wrote:
>> Aside: you forgot to call pass().
> 
> Not strictly necessary, since the test fails if and only if it throws.

Ok but it looks odd to print "pass 0 fail 0" ;-)

>>> 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.

To be specific it will depend on the exact call stack. In general you'll 
get the least permissions based on your stack. So if application code 
with no permissions calls library code with permissions, the 
doPrivileged in the library code says "only look at my permissions" - 
and so the call can work. But if the application code with no 
permissions calls doPrivileged then it still has no permissions. A 
doPrivileged by the application code will only have an effect if the 
application code has the necessary permissions but there is a frame with 
fewer permissions further up the stack.

Cheers,
David

> 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