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

[mandy chung]

On 9/11/18 12:34 PM, Alan Bateman wrote:
>>>
>>> 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.
>

Probably.  Also they might also wrap their call to javac with doPrivileged.

>>
>> 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.

I see this changeset is to get the source launcher to work with security 
manager so that launching in class file mode and source mode can specify 
the same runtime options.

You are right that it'd be a lot of effort to get jdk.compiler to work 
with callbacks and missing privileged blocks.  The minimum permissions 
are good for source launcher support.   If we were to drop the support 
for a security manager from the source launcher, I think jdk.compiler 
would need AllPermission due to callback.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180911/8e625c8f/attachment-0001.html>