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

On 10/24/2011 4:00 PM, Jeffrey Hutzelman wrote:
> On Sat, 2011-10-22 at 17:38 +0200, [email protected] wrote:
>> Note that there is a general and straightforward workaround - letting a
>> daemon use different Kerberos credentials for its own service and for
>> accessing the NFS service. This should be easy to setup (_is_ easy on
>> Linux, did not test on other client platforms).
> This is an important point.  Both convention and standards encourage the
> use of principal names of the form service/host.fqdn for host-based
> _services_.  However, the behavior of Sun's NFS notwithstanding, there
> is no similar convention dicating the use of user/host.fqdn to name
> principals belonging to _users_ on a particular host.  That is, while
> LDAP clients expect your LDAP server to have the principal name
> ldap/server.example.com, there is nothing that says that a process
> running as local user 'ldap' on host 'server.example.com' must or even
> should use that principal name when authenticating to other services.

Quite correct.  Not dictated.   But pity the administrator.  When one 
installs packages or ports on any of the unix progeny those come 
hard-wired from their maintainers with a user name all built in and 
created for you whether you prefer or no by the time the installation 
package has completed.   Just look in any /etc/passwd file of a busy 
server.   ldap, cyrus, nslcd, hast, bind, sshd.   And so on.  Local 
network applications follow the same convention.  None of them _require_ 
the user names to match.   But woe betide the administrator that creates 
more than one /etc/passwd entry with the same uid for processes that 
don't expect it.    For example, manage the transition between nfs3 and 
nfs4 shares.  Files written off-box via uid:gid now suddenly aren't 
owned in v4 world by the one of the formerly equivalent usernames.  
Unless you want to impose the joy of acl management.  Multiplying 
entities without good reason.

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.

It's almost always the case that there is at least some uid/username 
that's intended to be a one-one map to such a principal.  , the patches 
I offered create a way to indicate such, or others as well, or none.  
Whether or not the uid/username has such a creature as a 'default 
directory' in which a .k5login file might be placed.

>
> Of course, that doesn't help if for some reason you want everything
> running as 'ldap' on hundreds of machines to all be able to access files
> on the NFS server with the rights of (NFS server) user 'ldap', but don't
> want to give them all the key for the 'ldap' user.
>

A less extreme, more useful and actually in-use example is:  a family of 
directories, each shared in a way that limits access to one ip-- with no 
ability for that client principal/user to 'log in' interactively to the 
server.  Now each box's various services (some of which are user 
applications) will do what they did on their mounted remote directories 
before 'the kerberos regression':  be able to access their offsite files 
with their own user and group ids, now with kerberos wire integrity.  
But those files will not be available to principals with the same prefix 
on different boxes.  Just like they weren't before kerberos.



>
>> Services other than NFS and login do not need mapping to host-local names
>> anyway.
> Yes and no.  Certainly there are services other than NFS and login which
> result in access to files, processes, or other resources belonging to a
> particular user.  For example, ssh and FTP both fall into that class.
> Conversely, a file server does not necessarily need such a mapping; what
> it needs is a mapping to whatever it uses to track file ownership and
> access controls.  It just happens that a common NFS implementation model
> is to track such things using small integers in the same namespace used
> for tracking ownership of files and processes on the machine on which
> the server runs.  Of course, this is a terribly convenient model if the
> NFS server in question happens to simply export the contents of some
> local filesystem as-is.  But not all fileservers, nor even all NFS
> servers, work that way.
>
> -- Jeff
>
>