RFR: 8311532: Option to disable Krb5LoginModule::login method

Eirik Bjorsnos duke at openjdk.org
Mon Aug 14 16:50:58 UTC 2023


On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> JGSS is implemented in the JVM in 2 levels: the standard Java security provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The problem is that in this hierarchy, the login module doesn't go through the provider, but tries to read the credential cache (which is blocked by the credential guard in Win platform). This is not an issue if Kerberos is used via the JGSS API because it automatically does the JAAS login as needed, and won't do it at all if a native implementation is used. However many libraries (even some built-in ones in the JVM) still needlessly call login() before using JGSS.
> 
> This patch represents the configuration option ( `“doNotLogin”` ) to allow skipping the login, with a system property (`“sun.security.auth.skipLogin”`) to set the default value if this option is not provided. This way it would not break the regular Java Kerberos provider and allow users to both individually (via JAAS configs) and globally (via the property) set the expected behavior

Any particular reason why the configuration option is not called `skipLogin`? Seems to me that setting "doNot" to `true` requires a bit of unnecessary metal boolean algebra and is easier to get wrong. Or is this for consistency with `doNotPrompt`?

My general preference is to avoid using "negative" options such that when something is disabled or skipped, the value can be set to `false` instead of `true`. So I would prefer `doLogin=false` over `skipLogin=true`. But I guess this is a matter of preference and since all other configuration options seem to default to `false`, consistency might be an issue also in this regard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15254#issuecomment-1677662703



More information about the security-dev mailing list