[12] RFR(S) 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Jan 14 18:31:07 UTC 2019


Thank you Mandy for review.

Vladimir

On 1/14/19 10:29 AM, Mandy Chung wrote:
> 
> 
> On 1/14/19 9:39 AM, Vladimir Kozlov wrote:
>> Thank you, Alan
>>
>> On 1/14/19 2:27 AM, Alan Bateman wrote:
>>> On 13/01/2019 02:46, Vladimir Kozlov wrote:
>>>> http://cr.openjdk.java.net/~kvn/8216151/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8216151
>>>>
>>>> Have to update default.policy after changes in jdk.internal.vm.compiler.management files done by JDK-8199755: 
>>>> "Update Graal".
>>>>
>>>> Ran CheckAccessClassInPackagePermissions.java test.
>>>>
>>> cc'ing security-dev as that is where is the security policy file is maintained.
>>>
>>> One thing is double check is that code in jdk.internal.vm.compiler.management really needs to access members of 
>>> classes in the listed packages. I ask because the module definition doesn't export some of these packages to 
>>> jdk.internal.vm.compiler.management so they aren't accessible even when not running with a security manager.
>>
>> I verified that all listed packages are used by compiler.management and I listed only needed in default.policy. I used 
>> CheckAccessClassInPackagePermissions.java test to find which permissions are needed.
>>
> 
> I reviewed the change and the list matches the list of qualified exports from jdk.internal.vm.compiler to 
> jdk.internal.vm.compiler.management.
> 
> The security team has been looking into removing the private VM call out to ClassLoader::checkPackageAccess.  When 
> that's removed, we would not need to maintain these accessClassInPackage permission to access any new qualified exports.
> 
> Mandy



More information about the security-dev mailing list