JDK-8210274 : Source Launcher should work with a security manager
  • Type: Enhancement
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-08-31
  • Updated: 2021-06-25
  • Resolved: 2018-09-26
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 12
12 b14Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
Currently, the Single-file source launcher does not work when a security manager is installed. It should.

 source launcher fails when running security manager.

$ java -Djava.security.manager Main.java
Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.misc")
	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:322)
	at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1238)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:174)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:126)


Comments
A webrev containing an initial attempt at a full solution is here: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ With a review thread starting here: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012379.html Of note, during the course of this work, the following permissions were identified as necessary for javac to operate with a security manager: 114 115 grant codeBase "jrt:/jdk.compiler" { 116 permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete"; 117 permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; 118 permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc"; 119 permission java.lang.RuntimePermission "accessClassInPackage.sun.reflect.annotation"; 120 permission java.lang.RuntimePermission "accessDeclaredMembers"; 121 permission java.lang.RuntimePermission "accessSystemModules"; 122 permission java.lang.RuntimePermission "closeClassLoader"; 123 permission java.lang.RuntimePermission "createClassLoader"; 124 permission java.lang.RuntimePermission "getenv.JDK_JAVAC_OPTIONS"; 125 permission java.net.NetPermission "specifyStreamHandler"; 126 permission java.util.PropertyPermission "application.*", "read"; 127 permission java.util.PropertyPermission "env.*", "read"; 128 permission java.util.PropertyPermission "java.*", "read"; 129 permission java.util.PropertyPermission "jdk.*", "read"; 130 permission java.util.PropertyPermission "nonBatchMode", "read"; 131 permission java.util.PropertyPermission "user.*", "read"; 132 };
19-09-2018

It is not possible to make this work "well", without getting into the general problem of handling callbacks from javac (i.e. jdk.compiler module) when a security manager is in use. And that is beyond the scope of the the source launcher work. A partial solution is to update the MemoryClassLoader in the source launcher to set a CodeSource for any classes defined by that loader. This at least gives users the ability to set permissions on the script if they choose to run with a security manager. However, permissions for jdk.compiler will also need to be specified.
18-09-2018