RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth

[Weijun Wang]

On 7/11/2016 16:50, Mandy Chung wrote:
>
>> On Jul 11, 2016, at 4:15 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Hi All
>>
>> Please review the code change at
>>
>>       dev: http://cr.openjdk.java.net/~weijun/8159528/dev/webrev.00
>
> Good to keep the PLATFORM_MODULE list in alphabetical order. So java.security.jgss should be moved up.

The existing list in not in alphabetical order:

     jdk.jsobject \
     jdk.xml.dom \
     jdk.localedata \
     jdk.naming.dns \
     jdk.scripting.nashorn \
     jdk.zipfs \

Shall I reorder them?

>
>>   dev/jdk: http://cr.openjdk.java.net/~weijun/8159528/jdk/webrev.00
>>
>
> Two comments related to the use of unsafe here.
>
> You use reflection to get access to Unsafe instance to bypass the caller’s class loader check.  I think Unsafe::getUnsafe should be relaxed for null or ClassLoader::getPlatformLoader to access. On the other hand, we should also examine the use of Unsafe and see if they can be converted to VarHandle or other means.  Maybe you can file a JBS issue for Unsafe::getUnsafe to allow the platform class loader to access it and another one to examine the use of unsafe in java.security.jgss module.

JDK-8161129 filed. I didn't file a specific bug for java.security.jgss. 
I will be alerted once JDK-8161129 is resolved and I can file a bug then.

>
> I file a JBS issue to track this (JDK-8161121) to audit the callers of VM::isSystemDomainLoader and make appropriate adjustment.

Thanks
Max

>
> Mandy
>