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
