[32355] in Kerberos
Re: bug: krb5_get_host_realm() no longer uses DNS
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon May 17 14:50:21 2010
From: Greg Hudson <ghudson@mit.edu>
To: "Richard E. Silverman" <res@qoxp.net>
In-Reply-To: <m239xt8ttp.fsf@darwin.oankali.net>
Date: Mon, 17 May 2010 14:50:15 -0400
Message-ID: <1274122215.2419.209.camel@ray>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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.
> 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?
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
