RFR: JDK-8210274: Source Launcher should work with a security manager

[Jonathan Gibbons]

On 9/11/18 12:58 AM, Alan Bateman wrote:
> On 10/09/2018 21:37, Jonathan Gibbons wrote:
>> Please review a patch to have the Source Launcher be able to work 
>> when a security manager is enabled.
> It's not clear to me that this is an interesting use-case but in any 
> case I think you've got two scenarios to test. One is setting 
> java.security.manager on the command line, the other is the launched 
> code's main method calling System.setSecurityManager which amounts to 
> setting a security manager in a running VM. You might want to add a 
> test case for the latter.

I agree that this may not be a very interesting use case, and I have no 
strong feelings about whether or not to support it, except to say that I 
think we should specify the interaction between Source Launcher and the 
use of a security manager.  I note that this piece of work was triggered 
by the recent change to support the getResource* family of methods in 
the classloader used to run the user classes. At that time, it was noted 
that creating the URL involved directly calling a method that needed a 
privilege to be available (NetPermission specifyStreamHandler) (as 
compared to all the permissions indirectly required when invoking the 
compiler.)

As regards the interaction between Source Launcher and the use of a 
security manager, I see 3 possibilities:

1. Specifically support it, as provided in this webrev
2. No code change, but update JEP 330 to specify the behavior
3. Explicitly reject the combination of Source Launcher and the security 
manager.

>
> Is there any way (spi.ToolProvider or some means) for untrusted code 
> to indirectly run the source launcher? This question is important 
> because the updated source launcher could be abused to probe anywhere 
> on the file system.
Untrusted code can only run the source launcher by breaking 
encapsulation on the command line.  The source launcher is a combination 
of native code in the launcher itself and a class in an unexported 
package of jdk.compiler.  Even if you could access the source launcher, 
the compilation command line (i.e. the args for the internal call to 
javac) is highly constrained, and so it is difficult to see how the 
source launcher could be abused.
>
> What are the implications for uses of javax.tools and 
> com.sun.tools.javac.Main in code running with a security manager? 
> Maybe that is a separate project but I would have expected to see 
> privileged blocks in places that need permissions.
The intent was to stay clear (in this changeset) of all other ways of 
invoking javac, meaning javax.tools, com.sun.tools.javac.Main and 
spi.ToolProvider. While there are relatively few ways to invoke javac, 
these ways all permit the use of annotation processors and other 
callbacks, and so we would need privileged blocks in all places where 
callbacks could re-enter javac.
>
> -Alan

If we were to drop the support for a security manager from the source 
launcher, would you still consider it worthwhile to update the policy 
file to enumerate the privileges required to run javac? Setting aside 
the updates for the Source Launcher tests, I think the work to improve 
all the other tests to function better when a security manager is 
involved is also worth while.

-- Jon