On Wed, Oct 12, 2011 at 11:51:39AM -0500, Harry Coin wrote:
> Here and now, objectively, heimdal has a function, documented and not
> deprecated, that converts principal names to local names, that a 'grep
> -r' at the top of your favorite OS source tree shows is used by nfs at
> the least.
Ouch.
> So, which direction is it going to be, discussed to date we have:
>
> A1) Some have called this function's existence a bug
It looks like that.
> C) Let heimdal do A. But, offer a 'reference design' for B1 that OS
> implementers can use for guidance.
Ouch. The bug is "the belief that this can be done"
("once and for all services and setups"?).
> Meanwhile, this/that@realm owed by your:choice on linux nfs clients
> gets mapped to nobody:root on freebsd nfs servers, v3 and v4. No errors
> reported, no debug messages to be found. Thought it was about -maproot
> since my first encounter was root/<fqdn>, but no it's anything of the
> form this/that@realm. Rune suggests putting this/that in the freebsd
> passwd file.
Well, it may be appropriate to put such entries into passwd or not
(some scripts break if they encounter '/' in account names, i.e.
some scripts or programs are buggy...)
This is what whould work given "equality" mapping between principal names
and unix account names. If as you say there is some obscure heuristics
involved, then nothing can help to handle access rights consequently.
It is the passwd string->uid database on the NFS server which has to be
maintained to make privilege management consistent with how unix works
(the numeric uid being the credential used by the kernel for access
decisions). This is relevant for NFS exporting Unix file systems, of
course irrelevant for other services which may want to maintain their
own databases string->privileges.
> Basically, the tension comes as we'd like to avoid having ldap or
> similar entries for every network using process on every box with uid <
> 1000 as the uid/gid they are assigned varies across bsd, nix , is etc.
> We want local process/daemon uid:gids to stay entirely local.
You do not have to synchronize the server's idea of uids with the client
hosts' ideas, so allocate uids freely on the server, do not use that
database for nss on the clients. Done. That's where nfs4 finally allows
one to do right (but not with sec=sys).
The custom of synchronization of unix uids/gids over a campus existed
only for nfs's sake. There is actually no reason to have it this way
as soon as you throw out sec=sys.
Rune
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.