AFAIK, no permission check from RB::getBundle loading this resource bundle.
The implementation should wrap all security sensitive calls with doPriv. I
also mentioned that in [1]
I have a simple test that calls new X500Principal(null) and it runs fine with
security manager.
Mandy
[1] http://mail.openjdk.java.net/pipermail/security-dev/2017-January/015436.html
> On Jan 21, 2017, at 5:02 PM, Weijun Wang <[email protected]> wrote:
>
> Why isn't the new getAuthResourceString() using AccessController.doPrivileged
> anymore?
>
> Thanks
> Max
>
> On 01/22/2017 05:55 AM, Mandy Chung wrote:
>> Since AuthResources is the only altBundle, Max suggests to replace
>> getString(String, String) with a method for AuthResources bundle
>> specifically. It’s an alternative I considered too. Here is the revised
>> webrev:
>>
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.01/
>>
>> Mandy
>>
>>> On Jan 18, 2017, at 8:10 PM, Mandy Chung <[email protected]> wrote:
>>>
>>> Webrev at:
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/
>>>
>>> sun.security.util.ResourcesMgr::getString(String s, String altBundleName)
>>> is one existing mechanism to get the localized string from AuthResources
>>> and have sun.security.util.AuthResources resource bundle encapsulated in
>>> java.base.
>>>
>>> jdk.security.auth loads “sun.security.util.AuthResources” resource bundle
>>> in some place and uses ResourcesMgr::getString as well.
>>>
>>> This patch replaces direct loading of AuthResources resource bundle from
>>> jdk.security.auth so that jdk.security.auth does not need to access the
>>> resource bundle directly.
>>>
>>> I ran all core tests.
>>>
>>> Mandy
>>