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

[Jonathan Gibbons]

Please review a simplified solution to this issue.

It turns out to be not reasonable to make the source launcher work as 
well as might
be desired when a security manager is enabled, without addressing the 
bigger problem
of making javac (i.e. the jdk.compiler module) work well with a security 
manager,
and the related problems of handling callbacks from javac in such an 
environment.

In addition, working with a security manager is arguably beyond the 
scope of the
feature as described in JEP 330.

The simplified solution proposed here is just to use a protection domain 
with a
code source set to the source file when defining classes in the internal 
MemoryClassLoader.
This at least gives advanced users the ability to set permissions for 
classes in the
source file, if they also address or workaround the issues of 
permissions for the
jdk.compiler module.

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

-- Jon


On 09/10/2018 01: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