RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Nov 27 18:00:24 UTC 2017
Thanks! I pushed it.
Vladimir
On 11/23/17 7:40 PM, Jaroslav Tulach wrote:
> 24. 11. 2017 v 2:33, mandy chung <mandy.chung at oracle.com <mailto: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 <http://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