Source file launch with security manager enabled fails

[Ethan McCue]

While early learning was the goal, there are already build systems being
made that make use of the single file mode as a bootstrapping mechanism

https://github.com/sormuras/bach

That being said, it doesn't seem like it's a use case that deserves much
given that the security manager is deprecated for removal.

On Thu, Feb 3, 2022 at 8:38 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
> I think it would be useful to hear from Jon Gibbons or someone else
> working on javac first. It would be a bit unusual to run the compiler
> with a security manager and I thought it was deliberate to not grant
> permissions to jdk.compiler in the default policy. Also the source code
> launcher is aimed at the early stages of learning Java where there
> shouldn't be advanced options or exotic execution modes.
>
> -Alan
>
>
> On 03/02/2022 13:25, Sean Mullan wrote:
> > I only took a quick look, but it looks like a bug. The jdk.compiler
> > module needs to be granted that permission in the default.policy file.
> >
> > Please file a bug, or if you like I can file one on your behalf.
> >
> > Thanks,
> > Sean
> >
> > On 2/3/22 8:01 AM, Jaikiran Pai wrote:
> >> I'm unsure if core-libs is the right place for this or compiler-dev,
> >> sending this to core-libs for now.
> >>
> >> Please consider this trivial Java source file:
> >>
> >> public class HelloWorld {
> >>       public static void main(final String[] args) throws Exception {
> >>           System.out.println("Hello World");
> >>       }
> >> }
> >>
> >> Running this in source file launcher mode as follows:
> >>
> >> java HelloWorld.java
> >>
> >> returns the expected result. However when running in source file
> >> launcher mode *and* with security manager enabled, it throws the
> >> following exception:
> >>
> >> java -Djava.security.manager=default HelloWorld.java
> >>
> >> WARNING: A command line option has enabled the Security Manager
> >> WARNING: The Security Manager is deprecated and will be removed in a
> >> future release
> >> 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:485)
>
> >>
> >>       at
> >>
> java.base/java.security.AccessController.checkPermission(AccessController.java:1068)
>
> >>
> >>       at
> >>
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416)
>
> >>
> >>       at
> >>
> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332)
>
> >>
> >>       at
> >>
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184)
>
> >>
> >>       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> >>       at
> >> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132)
> >>
> >>
> >> This happens in Java 17 as well as latest master branch. I haven't
> >> checked older releases but I guess it's reproducible there too.
> >>
> >> Are users expected to use an explicit policy file to add this permission
> >> in source file launch mode or is this missing an internal doPrivileged
> >> call in the JDK?
> >>
> >> As an additional input, compiling this file first using javac and then
> >> launching it in traditional mode with security manager enabled works
> >> fine:
> >>
> >> javac HelloWorld.java
> >>
> >> java -Djava.security.manager=default HelloWorld
> >> WARNING: A command line option has enabled the Security Manager
> >> WARNING: The Security Manager is deprecated and will be removed in a
> >> future release
> >> Hello World
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220204/c599cbed/attachment.htm>