Theoretical data race on java.util.logging.Handler.sealed
Mandy Chung
mandy.chung at oracle.com
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.
Mandy
More information about the core-libs-dev
mailing list