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