Harry Coin wrote:
Hello group!
Looking for guidance on an ldap+NFS4+Kerberos puzzle in a mixed OS local environment.
Simple demo case, four computers on a little net.
box 1: Running openlap server, kerberos KDC, kadmin, lets say it's running freebsd, doesn't matter. nfs server& client. box 2: Linux box. nfs server& client. box 3: *bsd/Solaris box. nfs server& client. box 4: misc user box, could be *bsd or *nix.
Networking: Nfs4 secured with kerberos. That means No uid/gid numbers on the wire, only user@box. NSS is active on all boxes, reaching out to the ldap server on box 1 for info for what is not in the local passwd file searched first.
Popular package X gets installed on box 2 and box 3. Package X is a drop-root privilege package, has its own uid/gid!=0. It is active on the net, might write log files or get data files via nfs on either of the other two computers in the setup. The maintainers for package X in the *bsd world have chosen a different number for the uid / gid for the package X daemon than the maintainers for package X have chosen in the *nix world. Those get written in the local passwd file on each system at package X install / download time.
Note: Package X does _not_ get installed on the ldap server box #1, or box #4. There is no entry in the #1 or #4 system's passwd file for nss to find for the daemon associated with package X. nfsuserd via nss must find the package X user in ldap or the files will be unreadable or seem 'owned' by nobody:nogroup on 1 or 4 if say config or log files edited/accessed from there.
Puzzle: What should the posixAccount uidNumber and gidNumber value be in ldap for uid=packageXdaemon?
Alternatives:
1: Choose no entry, leave it out of the ldap db: PackageXDaemon's files will be owned by nobody:nogroup on box 1. Security Fail. 2: Choose *nix for the uid/gid in the ldap database on box 1. Fail: The files will be stored with a uid/gid that might collide with another account in the passwd database on the *bsd server. 3: Choose *bsd for the uid/gid in the ldap database on box 1: Fail: The *nix user on box 4's nfsuserid will get the bsd uid/gid from ldap which could create files not actually owned by something colliding in the *nix passwd database on box 4.
4: Instead storing all the users once under an ou=Account... create ou=AccountBSD and ou=AccountNix, duplicate the whole account tree but vary the apropos uid/gid pair under each tree with all the other remaining equal, manage collisions when amending the database. Not so pretty.
5: Edit the schema to replace uidNumber and gidNumber with uidNixNumber / uidBsdNumber& etc. for gid. Breaks code expecting standard uidNumber gidNumber in the default ldap schemas.
There are so many packages that could be X, you can imagine not wanting to have to qualify and patch all of them to use a common uid/gid number. (And it gets even worse in a mixed nfs3 / nfs4 environment where uid/gid numbers actually go over the wire in some cases, and user@box in others, let's leave that to the side for now).
I'm leaning toward #5 to avoid storing all the other account information under two different trees. But I'd prefer a scheme were there is a not-edited standard schema tree stored once under 'ou=Account' but with a different overlay for the uid/gid elements if looked up as AccountNix or AccountBsd.
I'm sure someone has done battle with this already, what's the right answer?
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=doc/drafts/...
Section 2.2.2
AFAIK nobody has implemented this feature yet, but it is the "right" solution.