Illegal package access when SunPKCS11 requires SunJCE's classes

The SunPKCS11 security provider might, on some circumstances, require help from SunJCE. An example of the previous is parsing X.509 public keys in P11DHKeyFactory::implTranslatePublicKey method. Usually, SunJCE access is performed through the Security::getProvider scheme. However, a fallback scheme that directly creates an instance from the SunJCE class is in place; in case the SunJCE security provider is not enabled.

The current JDK -probably any after JDK-8- is not ready to go through the fallback scheme when a Security Manager is installed due to access checks. There are a few issues preventing it:

1) the 'java.base' module does not export 'com.sun.crypto.provider' package to the 'jdk.crypto.cryptoki' module;

2) the default policy does not grant 'jrt:/jdk.crypto.cryptoki' code base 'accessClassInPackage.com.sun.crypto.provider' RuntimePermission; and,

3) even if permission were granted, we need privileged access in P11Util::getProvider method to prevent the check from going through the stack until the AppClassLoader (which does not probably have this permission).

Please note that the 'jdk.crypto.cryptoki' module already has permissions to access other 'java.base' packages such as 'sun.security.*'. Also note how this access requires the package to be exported to the module. I.e.: the 'sun.security.jca' package (from the 'java.base' module) is exported to the 'jdk.crypto.cryptoki' module.

Update: while SunPKCS11 might need to directly create instances of SUN and SunRsaSign provider classes, it already has access permissions through the 'java.base' exported modules and the default policy.