diehn.net/blog

At work, we have many Unix and Linux systems, so we use NIS to coordinate the authentication and authorization of users.  One of our Unix groups has so many members that the older Unix systems can’t “see” them all.  So, we split up the membership into a set of entries in the /etc/group file that all have the same numeric GID.

Looks like this:

dev:*:110:userAA,userAB,userAC,...,userBZ
dev1:*:110:userCA,userCB,userCC,...,userDA
dev2:*:110:userDB,userDC,userLastOne

And it’s been working pretty well. Until today, that is.

Today, I found a bug.

On “openhouse”, one of our SLES 11 machines, none of the users in the dev and dev1 groups were being recognized as being members of GID 110.  Only the members of dev2 had access to group 110.  It seems that dev2 appears last in the two group NIS maps.

On openhouse, /etc/nsswitch.conf had “compat” specified for passwd, shadow and group.

Now, “Compat” mode is to offer support for the +/- syntax we tend to use at the bottom of our /etc/{passwd, shadow, group} files.  The resolvers in “modern” distributions can manage without that +::: syntax if you simply include nis on the line in nsswitch.conf, but you loose a bit of functionality. For example, without compat mode, you couldn’t use this at the bottom of a file to allow access only for the members of a specific netgroup:

+@netgroup
-

Since we aren’t limiting access with netgroups on openhouse, I changed openhouse’s nsswitch.conf to the newer ‘files nis’ mode for passwd, shadow and group and now all the members of dev, dev1 and dev2 appear to be in group 110 again.

If we find systems on which we need to restrict access by using netgroups and yet can’t use “compat” mode, it’s likely that we can recover the access limiting functionality by using /etc/security/access.conf