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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jaroslav Tulach-4
Hi.
I believe I have a fix for JDK-8189116 - the
jdk.internal.vm.compiler.management needs only few permissions as shown in my
webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/

I have executed all the tests I found and it seems none of them regressed.
Also the Graal Compiler MX bean is properly exposed when the built JDK is
launched with

./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
+EnableJVMCI -XX:+UseJVMCICompiler -jar ...

Please take a look and review my changes. Thanks a lot.
-jt

Reply | Threaded
Open this post in threaded view
|

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

Mandy Chung


On 11/10/17 1:55 AM, Jaroslav Tulach wrote:
> Hi.
> I believe I have a fix for JDK-8189116 - the
> jdk.internal.vm.compiler.management needs only few permissions as shown in my
> webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/

The change looks fine.  This mainly depends on the test coverage and
also code inspection to find security-sensitive operations.
> I have executed all the tests I found and it seems none of them regressed.

You ran jdk_svc that should cover the management tests.   I assume you
also run Graal tests.
> Also the Graal Compiler MX bean is properly exposed when the built JDK is
> launched with
>
> ./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.  Is there a way you can access Graal MBean in a VM
with security manager enabled (locally is fine) to make sure it can be
accessed as expected?

This is good to go as long as you verify the access to Graal MBean with
security manager on.
Mandy
Reply | Threaded
Open this post in threaded view
|

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

Jaroslav Tulach-4
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-SNAPSHOT.jar

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.java:760)
        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(BuiltinClassLoader.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)

Reply | Threaded
Open this post in threaded view
|

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

Jaroslav Tulach-4
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-SNAPSHOT.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.java: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(BuiltinClassL
> 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)


Reply | Threaded
Open this post in threaded view
|

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

Sean Mullan
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-SNAPSHOT.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.java: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(BuiltinClassL
>> 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)
>
>
Reply | Threaded
Open this post in threaded view
|

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

Mandy Chung
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.

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-SNAPSHOT.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.java: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(BuiltinClassL
>>>
>>> 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)
>>
>>

Reply | Threaded
Open this post in threaded view
|

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

Jaroslav Tulach-4
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)


Reply | Threaded
Open this post in threaded view
|

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

Vladimir Kozlov
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)
>
>
Reply | Threaded
Open this post in threaded view
|

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

Mandy Chung
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)
>>
>>

Reply | Threaded
Open this post in threaded view
|

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

Jaroslav Tulach-4
24. 11. 2017 v 2:33, mandy chung <[hidden email]>:

> 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)
>>>
>>>
>