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

[Jonathan Gibbons]

Alan,

Thanks for all the feedback.  I'll add the extra test case you suggest.

-- Jon



On 09/11/2018 12:34 PM, Alan Bateman wrote:
> 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
>