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

Mandy Chung mandy.chung at oracle.com
Mon Jan 14 18:29:39 UTC 2019



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190114/7619503c/attachment.html>


More information about the security-dev mailing list