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

On 10/24/2011 9:49 PM, Booker Bense wrote:
> 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.

I see nor impose restriction on the number unique ids nor keytabs as you 
like -- within the context of services that understands what that's all 
about.   Just stray into the arena where that principal has to make 
sense among several applications not maintained by one group and it all 
changes.

All the atmospherics vented here with such finality.  Yet nobody on this 
list seems the least concerned that right here and now kerberos/heimdal 
style is incapable of allowing all existing applications to do as they 
did for all users prior, via the most standard and widespread inter-*nix 
os networking scheme out there: NFS.   Except offering wire level 
integrity and encryption to all users no matter the prinicpal names the 
admins happen to choose.   I do hear labels, identifications about what 
aspects are bugs, unwelcome architectural observations and so forth.

If someone has a better way to allow a principal with a / in the name to 
read and write over network shares, one that actually has been tested 
and works, other than the one I just wrote or MIT's kerberos, do tell.

Harry