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
