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

[Sean Mullan]

I have looked over the changes and they look reasonable, though I am not 
very familiar with this code.

I was wondering, when running with the PermissiveTestSecurityManager did 
you also have to enable security debugging (ex: 
java.security.debug=access) so that you log the permissions that were 
required? If so, it might be helpful to add that to the comments in the 
test. If not, how did you figure that out? - it's not immediately 
apparent when looking at the code.

--Sean

On 9/10/18 4:37 PM, Jonathan Gibbons wrote:
> 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