Permissions in default.policy and --patch-module

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Permissions in default.policy and --patch-module

Weijun Wang
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?

Thanks
Max

Reply | Threaded
Open this post in threaded view
|

Re: Permissions in default.policy and --patch-module

Alan Bateman
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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Permissions in default.policy and --patch-module

Alan Bateman
On 11/12/2017 07:50, Weijun Wang wrote:
> 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.
The only difference is that the classes on the patch path are in a
different location, hence have a different CodeSource and protection domain.
>
> This is similar to the case of exploded build.
>
The classes in an exploded build are located on the file system, hence a
file URL as the location and code source. I suspect you are asking for
jrt URL to work for exploded builds. Yes, this could be make to work
although the difference between exploded and images build pre-dates
modules (you'll have the same issue in JDK 8 with policy files that
grant permissions to JAR files in the run-time image).

-Alan