When a SecurityManager is enabled, early code paths that involve
ServiceLoader (SL) can trigger permission checks that cause parsing of a
custom policy file to fail due to recursive processing of the policy file.
I have fixed two of these issues which can occur under the following
conditions:
1. SecurityManager enabled
2. Signed JAR on the classpath
3. Policy file granting permission based on who signed jar and a
keystore entry containing the alias/key
4. Code triggering a permission check based on that grant
5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms
property in the java.security file
Parsing of the denyAfter constraint is required to verify the signed
JAR, which happens very early. This causes SL to search for a
LocaleProvider to parse the denyAfter date field which triggers a
permission check, causes the policy machinery to bootstrap, and which
triggers further permission checks, etc.
The first issue is that PKCS12KeyStore is unable to verify the integrity
of the keystore entry in the custom policy file because it cannot find a
"PBE" AlgorithmParameters implementation. I fixed this by adding
"SunJCE" to the list of providers that are automatically installed
during signed JAR verification.
The second issue is also in PKCS12 KeyStore where it tries to
instantiate a java.text.Collator which also uses SL and thus triggers a
recursive permission check. This was fixed by using a lazy
initialization Holder pattern.
webrev: https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8242565
More details and stack traces can be found in the bug.
Thanks,
Sean
