Null realms and servers
Nicolas.Williams at sun.com
Mon Dec 18 14:35:40 EST 2006
On Fri, Dec 15, 2006 at 09:25:46PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> Nicolas> On Fri, Dec 15, 2006 at 06:38:55PM -0500, Sam Hartman
> Nicolas> wrote:
> >> First, is it acceptable to release 1.6 in this stae. My gut
> >> feeling is that we will need to document the bug, but it is
> >> acceptable. It's not great and we want to fix it.
> Nicolas> IMO, no, it's not acceptable for
> Nicolas> krb5_sname_to_principal() to return a NULL realm.
> That's nice. The time for this comment would have been months ago or
> at the latest when the code was introduced.
I just spoke to Sam.
- The change to krb5_sname_to_principal() does not preclude the
host2realm fallback algorithm that Sun will be pursuing.
- I've convinced Sam that the fallback host2realm algorithm that I
described, in conjunction with referrals, will be very useful.
Specifically the algorithm we propose allows zero-configuration
clients to prosper in any environment that has the following
- Realm names correspond to DNS domain names, but without
necessarily having a sub-realm for every sub-domain. E.g.,
.sun.com = SUN.COM
.east.sun.com = SUN.COM
.central.sun.com = SUN.COM
- Hierarchical cross-realm relations are used
Add referrals and this will work with short-cut trusts also, plus
minimal KDC-side configuration (domain_realm relations only for
- We continue to disagree about whether the MIT change to
krb5_sname_to_principal() is a backwards-incompatible change.
However, even if MIT arrived at this change by error MIT is not
obliged to fix it before releasing 1.6. MIT may fix it later, in
1.6.1, if we subsequently agree that this is a backwards-incompatible
change (and we may not; I am open to being convinced that it isn't).
- Our difference here is a matter of how conservatively to estimate
what aspects of the behaviour of krb5_sname_to_principal() form
part of a stable API and what aspects of it are subject to change.
I believe that resturning a non-NULL, non-empty realm name is part
of its stable behaviour, whereas Sam does not.
- In any case, the change will not negatively impact any use of
krb5_sname_to_principal() in Solaris.
- Given the fuzzyness of the MIT krb5 API I would like to see a process
for reviewing potential changes to it.
And where a conservative view of a fuzzily-defined API is not
fundamentally incompatible with the feature that would motivate
changing that API then be conservative.
More information about the krbdev