RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

Jaroslav Tulach jaroslav.tulach at oracle.com
Fri Nov 24 03:40:39 UTC 2017


24. 11. 2017 v 2:33, mandy chung <mandy.chung at oracle.com>:

> I'm okay with this fix.

Just for the record: I am also fine with integrating my change.
-jt

> 
>> On 11/21/17 3:26 PM, Vladimir Kozlov wrote:
>> Do we have consensus about changes? I can sponsor and push it. 
>> 
>> These changes passed Hotspot pre-integration testing and additional requested tests. 
>> 
>> Thanks, 
>> Vladimir 
>> 
>>> On 11/15/17 5:44 AM, Jaroslav Tulach wrote: 
>>>> On úterý 14. listopadu 2017 21:34:45 CET mandy chung wrote: 
>>>> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services 
>>>> from JVMCI which is defined to the boot loader versus Graal is defined 
>>>> to the platform class loader. 
>>>> 
>>>>    java.security.AccessControlException: access denied 
>>>> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services") 
>>>> 
>>>> However Graal grants with AllPermissions. 
>>>> 
>>>> In any case, if this is an existing issue, I am okay if you file a 
>>>> separate issue to track this. 
>>> 
>>> Hello Mandy, 
>>> yes, it looks like issue unrelated to my changes. I have reported: https:// 
>>> bugs.openjdk.java.net/browse/JDK-8191320 
>>> 
>>> I hope I haven't messed up something on my disk and others will be able to 
>>> reproduce my problem. 
>>> -jt 
>>> 
>>> 
>>>> 
>>>> Mandy 
>>>> 
>>>>> On 11/14/17 2:02 PM, Sean Mullan wrote: 
>>>>> Try running with -Djava.security.debug=access:domain:failure 
>>>>> 
>>>>> This will tell you what ProtectionDomain caused the 
>>>>> AccessControlException, which should give you a better idea of where 
>>>>> the problem is. Look for messages that start with "domain that failed ". 
>>>>> 
>>>>> --Sean 
>>>>> 
>>>>>> On 11/14/17 1:22 AM, Jaroslav Tulach wrote: 
>>>>>> I tried the same test with 
>>>>>> 
>>>>>> changeset:   47679:d85284ccd1bd 
>>>>>> user:        sspitsyn 
>>>>>> date:        Fri Nov 03 17:09:25 2017 -0700 
>>>>>> summary:     8189731: Disable CFLH when there are no transformers 
>>>>>> 
>>>>>> and it also yields the exception. E.g. the problem is certainly not 
>>>>>> result of 
>>>>>> my changes. 
>>>>>> 
>>>>>> -jt 
>>>>>> 
>>>>>> PS: I try full rebuild on d85284ccd1bd maybe it disappears... 
>>>>>> 
>>>>>>> On pondělí 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote: 
>>>>>>> Hello Mandy, 
>>>>>>> 
>>>>>>> this was a good test: 
>>>>>>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX: 
>>>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ... 
>>>>>>>> 
>>>>>>>> You can also try running the above command with 
>>>>>>>> -Djava.security.manager 
>>>>>>>> as a sanity test (the application may need additional permissions) - 
>>>>>>>> just a sanity test. 
>>>>>>> 
>>>>>>> I've just tried: 
>>>>>>> 
>>>>>>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX: 
>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/ 
>>>>>>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHO 
>>>>>>> T.ja 
>>>>>>> 
>>>>>>> r 
>>>>>>> 
>>>>>>> and it doesn't work. I am getting an error below, however the code 
>>>>>>> is not 
>>>>>>> running through my module at all. I don't understand the failure, I 
>>>>>>> will 
>>>>>>> have to investigate more. 
>>>>>>> 
>>>>>>> -jt 
>>>>>>> 
>>>>>>> 
>>>>>>> Caused by: java.security.AccessControlException: access denied 
>>>>>>> ("java.lang.RuntimePermission" 
>>>>>>> "accessClassInPackage.jdk.vm.ci.services") 
>>>>>>>           at java.base/ 
>>>>>>> java.security.AccessControlContext.checkPermission(AccessControlContext. 
>>>>>>> java>>> 
>>>>>>> : 472) 
>>>>>>> 
>>>>>>>           at java.base/ 
>>>>>>> java.security.AccessController.checkPermission(AccessController.java:895 
>>>>>>> ) 
>>>>>>> 
>>>>>>>           at java.base/ 
>>>>>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558) 
>>>>>>>           at java.base/ 
>>>>>>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) 
>>>>>>>           at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680) 
>>>>>>>           at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678) 
>>>>>>>           at 
>>>>>>> java.base/java.security.AccessController.doPrivileged(Native 
>>>>>>> Method) 
>>>>>>>           at java.base/ 
>>>>>>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678) 
>>>>>>>           at java.base/java.lang.ClassLoader.defineClass1(Native Method) 
>>>>>>>           at 
>>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at 
>>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at 
>>>>>>> java.base/ 
>>>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206) 
>>>>>>>           at java.base/ 
>>>>>>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.ja 
>>>>>>> va:7 
>>>>>>> 
>>>>>>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda 
>>>>>>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683) 
>>>>>>>           at 
>>>>>>> java.base/java.security.AccessController.doPrivileged(Native 
>>>>>>> Method) 
>>>>>>>           at java.base/ 
>>>>>>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinCl 
>>>>>>> assL 
>>>>>>> 
>>>>>>> oader.java: 684) 
>>>>>>>           at java.base/ 
>>>>>>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java 
>>>>>>> :562 
>>>>>>> 
>>>>>>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at 
>>>>>>> java.base/java.lang.Class.forName(Class.java:451) 
>>>>>>>           at java.base/java.util.ServiceLoader.lambda$loadProvider 
>>>>>>> $1(ServiceLoader.java:856) 
>>>>>>>           at 
>>>>>>> java.base/java.security.AccessController.doPrivileged(Native 
>>>>>>> Method) 
>>>>>>>           at 
>>>>>>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858) 
>>> 
>>> 
> 


More information about the core-libs-dev mailing list