Theoretical data race on java.util.logging.Handler.sealed

[Peter Levart]

Hi,

While browsing the code of java.util.logging.Handler, I noticed a 
theoretical possibility that a security check in a j.u.l.StreamHandler 
be circumvented using a data race.

There is a plain boolean instance field 'sealed' in j.u.l.Handler that 
is pre-initialized to 'true' in field initializer. StreamHandler 
sublcass' constructors overwrite this value with 'false' at the 
beginning, then issue some operations which circumvent security checks, 
and finally they reset the 'sealed' value back to 'true' at the end.

If a reference to an instance of StreamHandler or subclass is passed to 
some thread without synchronization via data-race, this thread can see 
'true' or 'false' as the possible values of 'sealed' variable, thus it 
is possible to circumvent security checks.

One possibility to fix this is moving the field to StreamHandler and 
making it final:

http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.01/

Just making the field volatile might not work. There is an ongoing 
debate on concurrency-interest which suggests that volatile fields are 
not exceptional in constructors like final fields are...


Regards, Peter