RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

Daniel Fuchs daniel.fuchs at oracle.com
Thu Mar 24 17:56:50 UTC 2016


On 24/03/16 18:40, Mandy Chung wrote:
>
>> On Mar 24, 2016, at 7:52 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Mandy,
>>
>> Here is the new webrev - I have added comments for the
>> string constants as well as for the permissions passed
>> through to the limited doPrivileged call:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8150840/webrev.02/index.html
>>
>> I hope that it makes it more clear that the
>> java.util.logging.* properties are only used when java.logging
>> is present, and the jdk.system.logger.* properties when
>> java.logging is not present.
>>
>
> It looks okay. “jdk.logger.packages” is to specify which packages to be filtered and maybe better to rename it to “jdk.logger.filtered.packages”?

I am thinking about removing this property.
This was added before StackWalker was used. Now that we
have StackWalker, the inferCaller code will skip classes
that implement System.Logger - and this may be enough for
our purposes...
It's something I still need to ponder a bit more, so
I'd suggest handling the renaming or removing in a followup fix.

> About usage of limited doPrivileged, it’d be useful to have some guideline of using limited doPrivileged - I brought this up to Jeff when it was introduced and will ping him again.
>
> Like this example (in SimpleConsoleLogger.java)
>
>   476             String format = AccessController.doPrivileged(
>   477                     new GetPropertyAction(key), null,
>   482                     new PropertyPermission(DEFAULT_FORMAT_PROP_KEY, "read"),
>   487                     new PropertyPermission(JUL_FORMAT_PROP_KEY, "read"));
>
> The doPrivileged block simply reads a system property and one single security-sensitive operation.  It’s nothing wrong using limited doPrivileged in this case but I think it’s unnecessary.  Limited doPrivileged would benefit to limiting a block of code that is hard to tell what privileges are elevated.

This is precisely one of these cases where limited doPrivileged
should be used: otherwise you could abuse this method to read an
arbitrary property.


> getSimpleFormat should probably check the given key argument is either DEFAULT_FORMAT_PROP_KEY or JUL_FORMAT_PROP_KEY; otherwise throws IAE.  Otherwise, this method would pass if key is unexpected key if security manager is absent but fails if  security manager is present.

Oh - right - good idea. Replace the limited doPrivileged with
explicit argument checking :-) Let's do that.

Thanks for the comments!

-- daniel

> Mandy
>




More information about the core-libs-dev mailing list