> On 26 Jan 2017, at 03:32, Mandy Chung <[email protected]> wrote:
>
> (dropping jdk9-dev. security-libs is the appropriate list to review security
> permission)
>
>> On Jan 23, 2017, at 1:56 PM, Doug Simon <[email protected]> wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a
>> security manager is present. Since neither of these modules is accessible to
>> application code, it should be ok to give them all permissions. This seems
>> to be the approach for a number of other modules including
>> jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this
>> small change that configures this proposed permission level.
>>
>> http://cr.openjdk.java.net/~dnsimon/8145337/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8145337
>
> jdk.vm.compiler is defined by the application class loader and it’s used by
> AOT tool. I wonder why it has to run with security manager.
Without java.security.AllPermission, the policy for jdk.vm.compiler required to
get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions
-Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is
show below (annotated with comments denoting the methods requiring the
permissions):
grant codeBase "jrt:/jdk.vm.compiler" {
// org.graalvm.compiler.hotspot.HotSpotGraalJVMCIServiceLocator.<init>
permission jdk.vm.ci.services.JVMCIPermission;
//
org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties
permission java.lang.RuntimePermission
"accessClassInPackage.jdk.internal.misc";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
// org.graalvm.compiler.core.common.util.ModuleAPI.<clinit>
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.lang.RuntimePermission
"accessClassInPackage.jdk.internal.module";
// org.graalvm.compiler.options.OptionValue.<clinit>
permission java.util.PropertyPermission "graal.profileOptionValue", "read";
// org.graalvm.compiler.debug.Debug.<clinit>
permission java.util.PropertyPermission "*", "read,write";
// org.graalvm.compiler.core.common.UnsafeAccess.initUnsafe
permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";
// org.graalvm.compiler.hotspot.BootstrapWatchDog.<init>
permission java.lang.RuntimePermission "modifyThread";
permission java.lang.RuntimePermission "modifyThreadGroup";
// org.graalvm.compiler.hotspot.replacements.SHA2Substitutions.<clinit>
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.provider";
//
org.graalvm.compiler.nodes.graphbuilderconf.InvocationPlugins.resolveClass
permission java.lang.RuntimePermission
"accessClassInPackage.jdk.internal.reflect";
permission java.lang.RuntimePermission
"accessClassInPackage.oracle.jrockit.jfr.jdkevents";
};
There’s no guarantee that this is all the permissions required since not all
code paths are exercised during bootstrap.
> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not
> granted with any permission.
Neither of those tools create code and install it in the VM. I don’t think a
fine grained SecurityManager policy makes sense for a VM compiler since it
could subvert security by compiling/installing malicious code. That is, a VM
compiler has to be a trusted component. Keep in mind that user code cannot get
to jdk.vm.compiler.
For comparison, below are all the modules currently given
java.security.AllPermission by lib/security/default.policy:
grant codeBase "jrt:/java.activation" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/java.compiler" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/java.corba" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.incubator.httpclient" {
};
grant codeBase "jrt:/java.scripting" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/java.security.jgss" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/java.sql" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/java.sql.rowset" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.dynalink" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.internal.le" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.jsobject" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.naming.dns" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.scripting.nashorn" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.scripting.nashorn.shell" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.security.auth" {
permission java.security.AllPermission;
};
grant codeBase "jrt:/jdk.security.jgss" {
permission java.security.AllPermission;
};
