[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