bug: krb5_get_host_realm() no longer uses DNS

[Greg Hudson]

On Mon, 2010-05-17 at 16:32 -0400, Richard Silverman wrote:
> To me it seems simpler: krb5_get_host_realm() should, well... return the
> realm of the host. :)  If Kerberos is configured to do this via
> [libdefaults] dns_lookup_realm = yes, then it should do so
> consistently.

krb5_get_host_realm() cannot return "the realm of the host" if that
realm is best determined via referrals.  The configuration parameter
applies (post-1.6) to the behavior of krb5_get_credentials() if
configuration and referrals fail to produce an answer as to the realm of
the host.  It would be consistent with pre-1.6 behavior to make that
variable also apply to krb5_get_host_realm() if configuration produces
no answer, but not consistent with the value used by post-1.6
krb5_get_credentials().

> Well, often this is not possible; many servers have determination of their
> service principal hard-wired.  [...]

So... the practical concern here is that without
GSSAPIStrictAcceptorCheck false (or with stock OpenSSH), sshd fails if
the local hostname's realm cannot be determined through hardcoded
configuration, because gss_acquire_cred can't find "host/localhostname@"
in the keytab?

If so, there are a variety of ways to address that--but that problem is
only indirectly related to the behavior of krb5_get_host_realm().  The
responsibility chain here is gss_import_name -> krb5_sname_to_principal
-> krb5_get_host_realm.  If krb5_get_host_realm were reverted to the
pre-1.6 behavior, then krb5_sname_to_principal's behavior would revert,
causing gss_acquire_cred to succeed when it (I assume) currently
fails--but that would also have the effect of breaking client referrals
support.