Permissions in default.policy and --patch-module

[Weijun Wang]

I was just trying to run a jtreg test on a new Windows VirtualBox VM. A small code change is needed but I don't want to do a full build (it also does not have enough memory). I just copied an existing image, and the modified class was compiled on the host macOS machine.

So this is not "really a problem", but if --patch-module can be used to patch a module, I do hope the new classes are treated exactly the same as those existing classes.

This is similar to the case of exploded build.

--Max

> On Dec 11, 2017, at 3:20 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 11/12/2017 01:12, Weijun Wang wrote:
>> I modified a class inside the jdk.crypto.cryptoki module, compiled it with "javac -d /tmp", and then ran a small program with
>> 
>>   java --patch-module jdk.crypto.cryptoki=/tmp -Djava.security.manager MyProg
>> 
>> and it fails with
>> 
>> TEST RESULT: Failed. Execution failed: `main' threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.pkcs11")
>> 
>> Looks like the permission granted to "jrt:/jdk.crypto.cryptoki" in lib/security/default.policy are not granted to the new classes inside /tmp. If I duplicate the block for "jrt:/jdk.crypto.cryptoki" to "file:/c:/tmp" the program runs.
>> 
>> I thought the /tmp folder should be cascaded into the jrt file system for the module. Can this be enhanced?
>> 
> The behavior you see is expected as the classes in /tmp have a different code source and so are in a different protection domain. Sure, this could be changed so that the classes loaded from the patch path are in the same protection domain as the module but that isn't going to work when the patch needs different permissions. It also causes problems +TraceClassLoading (something we should separate at some point). Is this really a problem or is it mostly just tests?
> 
> -Alan