Dovecot SASL GSSAPI regression with krb5 1.18

[Simo Sorce]

On Mon, 2020-03-30 at 15:08 +0300, Mantas Mikulėnas wrote:
> Hello,
> 
> I have a mostly normal Dovecot 2.3.10 configuration with SASL GSSAPI:
> 
> 	auth_mechanisms = anonymous plain gssapi
> 	# auth_gssapi_hostname is unset
> 	auth_krb5_keytab = /etc/dovecot/dovecot.keytab
> 	auth_verbose = true
> 
> This used to work with MIT Kerberos version 1.17.1, and Dovecot would
> automatically determine the system's FQDN and would find the principal
> "imap/wolke.nullroute.eu.org at NULLROUTE.EU.ORG" in its keytab.
> 
> However, the principal search broke after upgrading to 1.18 -- now, each
> authentication attempt reports:
> 
> 	dovecot[1367034]: auth: gssapi(...): While acquiring service
> credentials: Unspecified GSS failure.  Minor code may provide more
> information
> 	dovecot[1367034]: auth: gssapi(...): While acquiring service
> credentials: No key table entry found matching imap/.nullroute.eu.org@
> 
> I have tracked this down to commit 99635376 "Qualify short hostnames
> when not using DNS". I'm still not entirely sure what is happening here,
> but it seems to me that Dovecot tries to pass an empty hostname to
> GSSAPI -- despite its docs saying that auth_gssapi_hostname should
> default to gethostname() -- and Krb5 canonicalizes that empty string
> resulting in a garbage domain name.
> 
> For now I can work around the issue in various ways: I could set
> 'qualify_shortname = ""' in krb5.conf to revert to old 1.17 behavior, or
> I could set 'auth_gssapi_hostname' in Dovecot to *actually* hold the
> system hostname or even the correct FQDN.
> 
> However, I'd much rather have everything work "by default" -- it did
> work in previous versions, after all -- and it seems to me that the
> check in k5_expand_hostname() should avoid canonicalization when `host`
> is an empty string, too.
> 
> So would this be considered a bug in krb5, or is it an expected change
> in behavior? (In addition to what I assume is a bug in Dovecot itself)

Sounds like Dovecot is passing an actual empty string instead of
GSS_C_NO_NAME, that's what you should fix, if you have no name you
shouldn't pass an empty string, you should pass a NULL gss_name_t

I think this is an unexpected use of the interface. It was never really
expected that users would pass an empty string for a name ...

I think it could be fixed for backwards compatibility, but you should
also open a bug in Dovecot and stop from using empty string in
gss_import_name()...

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc