RFR 8233222: KeyTab.getInstance().exists() has unspecified side effects preventing KerberosPrincipal instantiation

[Weijun Wang]

Please review the change below:

diff --git a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
--- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
+++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
@@ -106,10 +106,19 @@
      *
      * <p>If the input name does not contain a realm, the default realm
      * is used. The default realm can be specified either in a Kerberos
-     * configuration file or via the java.security.krb5.realm
+     * configuration file or via the {@systemproperty java.security.krb5.realm}
      * system property. For more information, see the
      * {@extLink security_guide_jgss_tutorial Kerberos Requirements}.
-     * Additionally, if a security manager is
+     *
+     * <p>Please note that when this class or any other Kerberos-related class
+     * is initially loaded and initialized, it might read the default realm
+     * from the Kerberos configuration file or via the
+     * java.security.krb5.realm system property. The default realm is cached
+     * (even if there is none) and any calls to subsequently set or change
+     * the default realm by setting the java.security.krb5.realm system
+     * property might be ignored.
+     *
+     * <p>Additionally, if a security manager is
      * installed, a {@link ServicePermission} must be granted and the service
      * principal of the permission must minimally be inside the
      * {@code KerberosPrincipal}'s realm. For example, if the result of

Here, the "Kerberos-related" class could be KeyTab as shown in this bug or something else like JAAS login configured with a Krb5LoginModule, or a JGSS call that touched the Kerberos 5 mechanism.

I used several "might" because this is just a hint but not a specified behavior and I don't want to restrict any evolution of the underlying implementation. For the same reason there is no test, although it's quite easy to trigger such a case. I've added a noreg-doc label.

Also, I assume there is no need for a CSR. This is not about compatibility or any new specification.

Thanks,
Max


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20191115/c4cb21d6/attachment.htm>