Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On Mon, 24 Oct 2011, Harry Coin wrote:

>
> Simple answers are the most maintainable and to be preferred.  I hope
> most agree that any deviation from
>
> "one uid <-> one username <-> one 'general purpose' kerberos principal"
>
> is an aberration that generates administrative headaches and needs
> justification to deploy.
>

I don't agree with this at all for anything that runs as a 
daemon or pretty much anything that reads it's secret from a
keytab. If it doesn't involve a human typing at a keyboard,
it doesn't apply, in fact I think the exact opposite should
apply.

An deamon required to act as a client to a kerberos service
should be able to specify an unique id and keytab for 
each service that it uses.

Your maxim breaks the principal of least privilege good and hard. 
It's incredibly bad design and anybody that has written a daemon 
that uses krb services that requires it should be embarrassed.

I've no desire to continue this thread, but I just felt I had
to make the point that what you precieve as common thought is far
from that for at least me and I suspect most people that have 
extensive kerberos experience. This is not "simple and 
maintainable" from where I sit.

Your patches are a hack to work around broken design. Nothing new 
there, but I think you'll have more luck if you present them in 
that light rather than as any kind of progress or simplification.
All I see is yet another work around for a poorly implemented 
application that will eventually result in CVE.

- Booker C. Bense