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
