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

[Jonathan Gibbons]

Please review a patch to have the Source Launcher be able to work when a 
security manager is enabled.

There are 4 parts to the work: an update to the default policy file, an 
update to the source launcher itself, updates to tests, and a custom 
security manager to help with testing.

1. src/java.base/share/lib/security/default.policy

Add reasonably fine-grain permissions to give javac the permissions it 
needs to run when a security manager is enabled. These permissions were 
determined by running all javac tests under with a special security 
manager installed: more on that later. There is one anomalous property 
which was detected, which is a property to control some internal javac 
behavior. Arguably, it should eventually be renamed with at least a 
"javac.*" prefix.

2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java

Update the source launcher to use doPrivileged in a couple of places: 
most notably around the main invocation of javac. Generally, it 
continues to be the policy that command-line tools like javac, javadoc 
do not use fine-grained doPrivileged blocks throughout the tool, and 
this update does not change that.  It is worth noting that when javac is 
invoked from the Source Launcher, it does not support callbacks like 
annotation processors, task listeners, and other plugin code, so that 
eliminates any issues relating to using callbacks from code in a 
doPrivileged block.

3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java

This is a custom new security manager for manual testing purposes in 
conjunction with jtreg, so that we can run a large subset of tests under 
the influence of a security manager. . It is a design characteristic of 
jtreg that almost all tests have their own distinct codebase, and so it 
is impractical to use a modified policy file to grant all necessary 
permissions to all necessary tests, so this security manager installs a 
custom Policy object that grants permissions to test code while 
deferring to the system policy for everything else (and for javac in 
particular.)   Using this security manager, it is possible to run all 
the javac tests to detect with high probability all the permissions that 
it requires. Using a custom security manager to install a custom Policy 
object allows the feature to be easily enabled on the jtreg command line.

There is one workaround in this security manager: a bug was uncovered 
such that the jdk.zipfs module needs permission to access the user.dir 
system property.  ( https://bugs.openjdk.java.net/browse/JDK-8210469 )  
A temporary workaround is used to get a clean test run.

Note: this code is not directly used in any normal/automated test runs 
for javac; nevertheless, it is deemed worthwhile to save the code for 
use in similar situations in the future.

4. Minor updates to tests.

Some new test cases are added to Source Launcher tests.

Although most tests are not directly affected by the use of a security 
manager, there are some exceptions. Some tests manipulate the security 
manager and/or expect the security manager to be unset.  These tests are 
modified to "pass by default" if the runtime conditions are not suitable 
(i.e. a security manager has been installed.)

Although it is not a requirement to be able to run annotation processing 
tests when a security manager is enabled (because that condition cannot 
arise with the Source Launcher), most annotation processing tests do run 
successfully. There were 3 exceptions, where the test required more 
permissions than granted to javac in code being called from javac. These 
permissions were to access test.* system properties and the setIO 
runtime permission. Rather than grant unnecessary properties to javac, 
it was enough to use doPrivileged in a couple of places in the javac 
"toolbox" test library, and to refactor those tests to better use toolbox.

In conjunction with these changes,ignoring any tests on the ProblemList, 
all javac tests pass, with and without a security manager being present.


JBS: https://bugs.openjdk.java.net/browse/JDK-8210274
Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/


-- Jon