Permission Bug in AtomicLongFieldUpdater and AtomicIntegerFieldUpdater

Martin Buchholz martinrb at
Thu Apr 15 15:34:22 PDT 2010

Hi java.util.concurrent security team,

People are using Atomic field updaters to update fields in classes in
other classloaders.

Toby writes:

We received a bug report for App Engine that AtomicLongFieldUpdater
(and its sibling) were failing with RuntimePermission
accessDeclaredMembers. Looking at the code, it appears that it is a
bug for that permission to be required. AtomicLongFieldUpdater (and
sibling) are already performing subsequent access checks that ensure
that the caller isn't accessing a field it shouldn't be. I've attached
a patch which moves the field lookups into doPrivileged blocks.


There was a bug was filed by ehcache folks. I could follow up with
them to see if I could get some pointers to actual usage, if you're
looking for motivational reasoning.


GAE Bug Submitter writes:

AtomicLongFieldUpdater is broken in the production sandbox.

The simple test application that I wrote (atomically increments and prints
a volatile long on each get request) works perfectly in the development
environment.  In production creating the field updater fails with an
AccessControlException when the internal CASUpdater tries to do reflection
(on a user class) in order to get a reference to the volatile field.

I've attached the test app which works perfectly in development but fails
in production.

This issue is linked to an associated Ehcache issue:

I have a modified experimental version of Toby's patch against openjdk7 here:

I'm afraid to touch this security stuff myself,
especially where we might be loosening permissions,
but in principle I agree with Toby.
(Even though atomic field updaters were designed to be
used within a module (whatever that is))

The doPrivileged should not be too costly, as it's
only performed at updater creation time.


More information about the security-dev mailing list