<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 9/11/18 12:34 PM, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com">
<blockquote type="cite">
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
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.
<br>
</blockquote>
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.
<br>
<br>
</blockquote>
<br>
Probably. Also they might also wrap their call to javac with
doPrivileged.<br>
<br>
<blockquote type="cite"
cite="mid:0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com">
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
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.
<br>
</blockquote>
<br>
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. <br>
<br>
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.<br>
<br>
Mandy<br>
</body>
</html>