Group Merging

Implemented as of commit ced8f8933673f4efda1d666d26a1a949602035ed on April 29th 2016.

1. Problem Statement

Many Linux applications rely on a user's membership in a group to define access-control rules. In many cases, these groups are hard-coded by the application (particularly third-party and closed source applications). This can make managing access control very difficult in an environment where users are being managed by a central domain such as FreeIPA or Microsoft Active Directory.

In most cases, when a package is installed on the local system, it will create the management group it requires for operation. In order to manage membership in this group centrally, there are generally two mechanisms that are used, both with flaws.

  1. A configuration management tool such as puppet, chef or ansible is used to distribute edits to the /etc/group file across machines.
    • Pros: Configuration management can handle differentiating the hard-coded group from different machines.
    • Cons: Configuration management requires additional infrastructure beyond simply a domain controller/directory.
  2. The local entry for the group is removed from the /etc/group file and it is maintained in the directory.
    • Pros: The group is always managed from the directory, so there is a single place to maintain changes to your entire infrastructure.
    • Cons: It's very difficult to produce a different version of a group for different machines (requires LDAP views or similar technology). It also does not allow you to easily manage machine-local accounts as opposed to domain accounts.

At present, the name-service interface will (by default) stop at the first entry in the nsswitch.conf backend list for which a lookup succeeds.

2. Proposal

We propose the addition of a new directive in the nsswitch.conf for the 'group' database. We would like to see [SUCCESS=merge] added that will behave as follows (using the example of the 'files' and 'sss' backends to illustrate).

/etc/group contains the following line:


When requested directly from the 'sss' backend, we would receive:


In the current case, with the standard nsswitch.conf configuration, we see:

[user@system:~]$ getent group wheel

This proposal suggests adding the following directive added:

group: files [SUCCESS=merge] sss

The effect would be for the output to now show:

[user@system:~]$ getent group wheel

3. Special Cases

3.1. Group name and GID do not match between databases

The glibc interface should verify that all subsequent lookups of the group return the same name/GID pair. If they do not, that database should be treated as NSS_NOTFOUND.

This is to avoid situations where an LDAP or other database might have a different GID number for a particular name (or vice-versa). In those cases, we should simply ignore them and rely only on the previous databases (usually 'files').

This restriction is in place to make getgrnam and getgrgid consistent, so that looking up by gidnumber returns the same result as looking up by group name, sticking to the example above looking up by gid number = 10 gives the same list of users:

[user@system:~]$ getent group 10

3.2. Group membership has overlap between databases

The glibc interface that is managing the databases should perform a uniqueness check so that it only returns a single instance of the member user name.

3.3. Iterating over all groups and merging

The getgrent, setgrent, endgrent functions iterate over all entries in all databases. Multiple backends may have the same group. For a database with a MERGE after it, you must lookup the group in the next merged NSS backend, and merge, before returning the iterated result. Then when you move to the next backend, you must skip those results you already reported earlier. Merging is probably the only sane answer to make these functions return similar results to the other functions. The end effect is that the chain of merged backends acts as-if it were a single unified merged backend with respect to the set of returned results from iteration.

4. Implementation notes

5. Authors

None: Proposals/GroupMerging (last edited 2017-05-09 20:13:43 by CarlosODonell)