Martin Buchholz said the following on 04/16/10 16:58:
On Thu, Apr 15, 2010 at 19:04, David Holmes <david.hol...@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

Reply via email to