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

[Alan Bateman]

On 11/09/2018 19:42, Jonathan Gibbons wrote:
> :
>
> 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.
Since you've started into this then it's probably best to just continue 
with #1 and get it done. My main point here was the test in the webrev 
sets the security manager on the command line and I think you also need 
another test that sets in the test main method.


>>
>> 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.
Thanks, the question had to be asked because the privileged block in the 
source launcher main means it can access any file.

>>
>> 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.
That is what I was wondering about it. I don't see a queue at the door 
of developers looking to run javac with a security manager but at the 
same time it is possible to configure many app servers with JSP support 
to run with a security manager. I assume they must have historically 
granted at least some permissions to "tools.jar" for this to work.

>
> 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.
It took a lot of work in JDK 9 to identify the minimum permissions 
needed by several modules. The java.xml.bind and java.xml.ws modules 
took a lot of effort because of the callbacks and missing privileged 
blocks. It does take a lot of effort and testing to be confident. So my 
personal view (and not my call) is that it's probably not high priority 
to do the same for jdk.compiler at this time.

-Alan