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

Mandy Chung mandy.chung at
Wed Dec 18 22:13:35 UTC 2013

On 12/18/2013 5:55 AM, Peter Levart wrote:
> On 12/17/2013 06:43 PM, Mandy Chung wrote:
>> Can you check what methods are called by the constructors whose 
>> access are denied in the current implementation but granted in the 
>> patch?  I have to take another look to make sure but I believe they 
>> only calls the methods in the handler classes that calls 
>> Handler.checkPermission.
>> Mandy
> Methods that are called by various Handler constructors and would be 
> elevated by doPrivileged are:
> - Handler's own setters, protected by Handler.checkPermission - 
> "control" permission required,
> - LogManager.getLevelProperty - no special permission required
> - LogManager.getFilterProperty - loads class configured in properties 
> from system class loader and instantiates it. (since this is done by 
> system class - LogManager, no special permission required besides 
> those that might be imposed by constructor of the Filter (sub)class)
> - LogManager.getFormatterProperty - the same as getFilterProperty
> - LogManager.getStringProperty,getIntProperty - no special permission 
> required
> That's about it. So the only methods that are not known and would be 
> elevated by doPrivileged are no-args constructors of Filter and 
> Formatter subclasses the names of which are obtained from logging 
> properties and which must be loadable by system class loader.

Thanks Peter.   The use of limited doPrivileged is okay then.


More information about the core-libs-dev mailing list