bug: krb5_get_host_realm() no longer uses DNS

[Richard Silverman]

On Mon, 17 May 2010, Greg Hudson wrote:

> On Sat, 2010-05-15 at 04:14 -0400, Richard E. Silverman wrote:
>> Somewhere between 1.5.4 and 1.8.1, this code was removed from
>> krb5_get_host_realm() and moved to krb5_get_fallback_host_realm():
> [...]
>> Am I missing something, or is this just a bug?
>
> This happened in krb5 1.6, as part of referrals support.
>
> It's definitely a behavior change, and has had some other negative
> consequences.  I've considered restoring the old behavior of the API,
> but haven't quite convinced myself that it's a good idea.  The API can't
> fully match the behavior of the TGS code since we can't perform
> referrals without a TGT in hand, so perhaps it's better to give the
> caller both pieces of what we broke (krb5_get_host_realm and
> krb5_get_fallback_host_realm) instead of gluing them awkwardly back
> together.

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.
In my system, this was further complicated by the (welcome) introduction
of client-side referral support.  After the krb5_get_host_realm() change,
the clients get the wrong realm -- but then get referred, so the client
side continued to work.  But not every realm to which my clients speak
perform referrals, and anyway the server doesn't have the benefit of this
when determining its own realm.

>> If a server determines its realm via
>> a TXT record, e.g. for gss_acquire_cred(), then it now fails where it
>> worked in earlier versions (this has bitten me with OpenSSH).
>
> Is there a reason your server needs to use gss_acquire_cred with a
> specified name, as opposed to just passing null credentials to
> gss_accept_sec_context, or a null name to gss_acquire_cred?

Well, often this is not possible; many servers have determination of their
service principal hard-wired.  In this particular case it is possible,
since my OpenSSH build has a GSSAPIStrictAcceptorCheck parameter.
However, then ideally I should place a copy of the host principal in an
OpenSSH-specific keytab.  OpenSSH does not have a parameter for keytab
location, so I have to modify the startup process to set
KRB5_KTNAME... and so on.

- Richard