[concurrency-interest] Concurrency and security

Gregg Wonderly gregg at cytetech.com
Thu May 20 17:05:28 EDT 2010

Kai Meder wrote:
> On 20.05.2010 07:47, Yao Qi wrote:
>>> Oops! Indeed. Even with sync the API is fatally flawed.
>>> I don't know if the tools will be able to detect the inherent check-then-act
>>> sequence.
>> David, this kind of error is regarded as "atomic violation".  I don't
>> know either if tools can detect such errors *accurately* and
>> *efficiently*, even there are a lot of papers on this topic.
> May anyone post a simple yet non-flawed API avoiding check-then-act?

There are two ways that you really should manage secure execution in Java.

To limit what a user can do, use Subject.doAs() with a JAAS authenticated 
javax.auth.security.Subject to allow permission checks to consider the 
Principal(s) represented in the Subject.

To perform actions on behalf of a user that you want to override their 
permissions with, use AccessController.doPrivileged(), which will use the 
privileges granted to the AccessControlContext of the class making such calls, 
instead of using the AccessControlContext of the thread and classes calling into 
such code.

Examples like this should really no longer be used.  JAAS really makes it 
possible to do things much more securely by using Principal(s) and/or 
AccessControlContext(s) of the threads so that there is no "global" access 
control performed and thus no concurrently mutated access control.

Gregg Wonderly

More information about the Concurrency-interest mailing list