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

[Jonathan Gibbons]

Updated webrev against the latest jdk/jdk sources.

No change in the updates for this feature (just changes in the 
surrounding context)

Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.02/

-- Jon

On 09/20/2018 01:29 PM, Jonathan Gibbons wrote:
> 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
>