Re: nfs client 'nobody no matter what' clarification was Re: k5userok .c / doc mismatch

On Fri, Oct 14, 2011 at 10:16:45PM -0500, Harry Coin wrote:
> Now, these daemons are inter-related nfs clients  that update files on 
> all manner of file services and servers.   The whole local world 

Nothing prevents you from allocating account names of any form, like
service-XYZ in the passwd database of the NFS-server(s). Then give the
corresponding NFS-client's service daemon's uid a keytab for principal
named [email protected] and let it fetch the corresponding tgt,
and you are done. The local uid of the daemon is of no interest.

It is sufficient if a separate process with the daemon's uid fetches a TGT
for the [email protected] (and refreshes it). The daemon may remain
fully unaware why it is able to access the NFS areas which it needs.

I suspect you take too many of the exsting practices' limitations
as a reflection of reality. No.

- you do not need to swich the whole OS to a different library if
  you need the corresponding functionality for a certain application

- you do not have to synchronize:
  - numerical gid/uids between different computers
  - principal names with local account names which are using the identities
  - passwd databases between NFSv4 servers and clients
  - the Kerberos identity being used to verify the clients of a service
    and the identity used by the service daemon as another service
    client (say, for NFS' sake)

As one of the consequences, I do not see why you'd need any complicated
mapping between principals and host-local account names.
As another one, you do not have to rely on LDAP, this may relieve
some pains.

Hope this helps somehow.

Regards,
Rune