JPMS Access Checks, Verification and the Security Manager
Volker Simonis
volker.simonis at gmail.com
Tue May 23 14:44:11 UTC 2017
On Tue, May 23, 2017 at 10:20 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> Volker - one suggestion for your experiments is to change your JDK 8
> security properties file (java.security) to add "com.sun.crypto.provider."
> to the value of the "package.access" property. That should mean you will get
> the same AccessControlException with JDK 8 as you do with JDK 9. It may help
> to reason about the JDK 8 behavior, including what is triggered by
> verification, before looking at 9.
>
You're right. JDK 8 produces the same error if we add
"com.sun.crypto.provider." to the value of the "package.access"
property. I didn't wanted to blame jdk9 here - I just saw this
difference because "com.sun.crypto.provider." isn't contained in the
"package.access" property by default.
So maybe I rephrase my question a little more generally:
Is it required for the verifier to do security and/or access checks
during the verification phase or could/should these checks be
postponed to runtime? The issue with verification errors due to
missing classes from Remi's previous answer is probably a corner case
of this question.
The other question is if '--add-exports' should implicitly grant the
corresponding security permissions? I understand that package/class
visibility and security checks are somewhat orthogonal concepts so I
tend to agree with the current functionality (and a part of this
problem is now tracked by JDK-8174766). Nevertheless it is probably
wise to document these differences so people won't get surprised.
> On the "Error: A JNI error has occurred, please check your installation and
> try again" message. It's not core to your questions of course but I agree it
> is confusing. Ramanand Patil had a number of attempts on core-libs-dev to
> improve this and it may be that more is needed there.
>
Yes, a better error message would be nice but thats a different question.
Thanks,
Volker
> -Alan
>
More information about the security-dev
mailing list