Re: root/ host/ <uid 0 service like nfs>/ ?!?

On 10/5/2011 4:33 AM, [email protected] wrote:
> On Tue, Oct 04, 2011 at 04:57:38PM -0500, Harry Coin wrote:
>> There is clarity as principals when people have their account and their
>> account/admin principals.   Hoping to extend that clarity to the root /
> If you look a bit deeper, there is no "clarity". There are some practices,
> traditions and things which the API suggests and/or KDC implementation
> allows.

In this open source software world, practices and traditions that last 
for more than a year or so defacto define such 'clarity' as might be.

I appreciate your efforts in writing responses.  Kindly as an experiment 
adopt the point of view of those tasked with building systems to be used 
by people who have their plates quite full in their own non computer 
domains of knowledge and production needs, in the context of time 
pressure.  End-users who can't possibly be expected to add comprehension 
of the 'inner life of the many component packages'; and Technology staff 
who will avoid this entire solution space if forced to be as a 
bricklayer given bricks that don't quite fit together when it's time to 
scale everything up and put it all under heavy all-the-time load.

  The authors and maintainers of these packages, such as yourself, have 
clear visions and organized ideas which use words like 'should' and 
'ought'.  You've expressed them quite clearly.    Each maintainer knows 
their world best, and knows their vision for its future.   However these 
maintainers, they don't speak to one another so much.   They read the 
documentation they are given by their peer maintainers, and generally 
stop reading that other material the moment they are done comprehending 
command line options and configuration file formats.   Those given to 
assemble all this are even more prone to that.   They/We really need 
their own package to 'just work', so they do things like linux did in 
its nfs client, throwing spaghetti at the keytab wall until it finds one 
that 'sticks'.  So as to avoid having bug reports filed by the hundreds 
cross platform.   Note nfs is a package used more than kerberos-- so it 
has to work.  That's where the tire meets the street.

We who are given to stitch it all together in the here and now are in 
the manner of the last ice-skater in the long whip chain-- we must cause 
all these packages to work in combination, and right soon.  Many of us 
live in a world where tomorrow's pay depends on today's delivery of value.

So, have some pity on we less immortal types, possibly write in plain 
'do this' language a __cross platform friendly__  kerberos-centric 
principal naming convention,  with a real-world example to pattern 
after, that has a future, that has these features:

1.  -sec=krb5p nfs system clients (fstab mounts) and user clients 
(uid!=0 mounts)  and nfs servers will play nicely no matter the 
client/host os.
2.  ldap,  pam and nss, nslcd  don't get confused in operation, and know 
their (sometimes system, sometimes person) client / service principals.
3.  Makes it possible to look at a principal name and know if it is 
intended to be used by a person or not.
4.  Accepts the real-world fact that 'root' is and will always be an 
account that presupposes a person might be directly involved, not a 
service, but might not be the same person on different boxes.
5.  If a principal is not a person, then some way to deduce its service 
family, where it fits in a 1 to 1, or 1 to many, or many-to-many 
arrangement, and if it belongs to just one box the fqdn.  (You can 
imagine a realm-wide principal giving restricted ldap access, for 
example, even if using box specific SSL over the wire).
6.  Samba and the Redmond cousins have a chance at interoperability.
7.  Is unconcerned with the uid/gid of any principal, but does not adopt 
a above-it-all indifference to the consequences its own 'default' 
choices that presuppose keytab access among various packages by more 
than one uid.  (Okay, this one really isn't about principal names... or 
is it?)

I understand the heimdal / MIT types can't be responsible for what all 
the other maintainers do.   But I think it's clear a target organizing 
principal naming prinzip needs developing and probably best led and 
articulated for consideration from here.

My ha' penny of a Wedneday morning.