RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean
mandy chung
mandy.chung at oracle.com
Fri Nov 24 01:33:01 UTC 2017
I'm okay with this fix.
Mandy
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