JDK-8189116 : Grant only required permission to jdk.internal.vm.compiler.management module
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-10
  • Updated: 2019-09-13
  • Resolved: 2017-11-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b36Fixed
Related Reports
Blocks :  
JDK-8191320 - Can't run JVMCI compiler with security manager on
Relates :  
JDK-8188775 - Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
Relates :  
JDK-8216151 - [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug
Description
JDK-8188775 granted AllPermission to  jdk.internal.vm.compiler.management module. But only accessClassInPackage.org.graalvm.compiler.hotspot was required in that case.
Comments
Webrev.01 is ready at http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/
10-11-2017
You need to submit formal review request RFR on mailing list.
09-11-2017
[~kvn], can you please integrate my most recent changes, if you believe they are correct? diff -r d85284ccd1bd src/java.base/share/lib/security/default.policy --- a/src/java.base/share/lib/security/default.policy Fri Nov 03 17:09:25 2017 -0700 +++ b/src/java.base/share/lib/security/default.policy Thu Nov 09 09:51:43 2017 +0100 @@ -155,7 +155,10 @@ }; grant codeBase "jrt:/jdk.internal.vm.compiler.management" { - permission java.security.AllPermission; + permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.hotspot"; + permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.runtime"; + permission java.lang.RuntimePermission "accessClassInPackage.sun.management.spi"; + permission java.lang.RuntimePermission "sun.management.spi.PlatformMBeanProvider.subclass"; }; grant codeBase "jrt:/jdk.jsobject" {
09-11-2017
Do you remember when you pulled from jdk10/hs? It should be fixed by JDK-8189193 on Oct 20. I would suggest to update you local repo to latest jdk10/hs and rerun again with you changes. After testing finished, use Ioi's DFKL tool to review results and filter out known failures: http://ioilinux.us.oracle.com/cgi-bin/dkfl in "Filter" specify your mach5 job id or select it if you see on the list.
03-11-2017
Ah yes I'd missed that since the I'd forgotten that the module name doesn't include graal even though the packages are all org.graalvm. Graal is of course an obvious use case but assuming some enterprising person decided to attempt the same task they would need the same AllPermissions grant which conceivably could be automatic but I guess it'd just as easy to require any replacements to include their own updates to the policy file.
26-10-2017
With following change: {code} $ hg diff diff -r 39575526c6d9 src/java.base/share/lib/security/default.policy --- a/src/java.base/share/lib/security/default.policy Thu Oct 12 01:18:38 2017 +0000 +++ b/src/java.base/share/lib/security/default.policy Wed Oct 25 16:41:43 2017 +0200 @@ -155,7 +155,9 @@ }; grant codeBase "jrt:/jdk.internal.vm.compiler.management" { - permission java.security.AllPermission; + permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.hotspot"; + permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.runtime"; + permission java.lang.RuntimePermission "accessClassInPackage.sun.management.spi"; }; grant codeBase "jrt:/jdk.jsobject" { {code} I was able to run all jtreg tests: {code} test/jdk$ ~/bin/jtreg/bin/jtreg -testjdk:$JAVA_HOME -v java/lang/SecurityManager/ Test results: passed: 5 {code}
25-10-2017
ILW = All security permissions granted instead of minimal possible; only for new module jdk.internal.vm.compiler.management; no workaround = MLH = P4
12-10-2017
OK.
10-10-2017
[~jtulach] Jaroslav, please look if you can find what minimum permission is needed for this module.
10-10-2017
First, need to find minimum permission to grant. accessClassInPackage is enough for JDK-8188775 case but other cases may need other permissions.
10-10-2017