Kadmin service principal revisited

[Sam Hartman]

I'm sort of disappointed in the responses I got on this issue.  The
responses seemed to fall into two categories: responses that focused
on the wrong issues or responses based on false assumptions about how
the proposed patches actually work.

The focus on the wrong issues are my fault and I'll try and clarify
what I'm asking about.  The client handling of the behavior is
actually reasonably simple.  The proposed patches do not seem to do
all the canonicalization steps I'd expect; they seem to pull a name
directly out of a configuration file and not canonicalize it
additionally.  But that can be changed.  The only real client-side
concern is the change in the meaning of the arguments to the kadmin
API.

The real concern is on the server side and on database setup.  That's
where gethostname() is called and where a hastname-based principal
name is used.

I don't think Doug's point--comparing this behavior to host-based
principals--is particularly valid.  First, it's not actually the same
as a host-based principal; it is subtly different than how host-based
service names are handled in GSSAPI.  IN particular, there is an
additional gethostbyaddr reverse resolution call in that code path.
But I'm more concerned about usability regressions when compared to
the previous kadmin than about whether other parts of the system have
the same usability bugs.

Many people suggested allowing multiple principal names.  That's not
supported by the contributed RPC library either at the API or code
level.  Using GSS_C_NO_CREDENTIAL is not an acceptable option, because
the "keytab" in question is the entire KDC database.  I could add
support--either using GSS_C_NO_CREDENTIAL and then checking the
result, or using several credentials and trying each.  

But my question is what is the justification for this work.  Do we get
anything out of kadmin/hostname over kadmin/admin than Sun
compatibility?  I'm not saying that Sun compatibility isn't enough,
simply that I want to understand what tradeoff I'm making.