NSS: Implement group merging support.

https://sourceware.org/glibc/wiki/Proposals/GroupMerging

== Justification ==
It is common today for users to rely on centrally-managed user stores for
handling their user accounts. However, much software existing today does
not have an innate understanding of such accounts. Instead, they commonly
rely on membership in known groups for managing access-control (for
example the "wheel" group on Fedora and RHEL systems or the "adm" group
on Debian-derived systems). In the present incarnation of nsswitch, the
only way to have such groups managed by a remote user store such as
FreeIPA or Active Directory would be to manually remove the groups from
/etc/group on the clients so that nsswitch would then move past nss_files
and into the SSSD, nss-ldap or other remote user database.

== Solution ==
With this patch, a new action is introduced for nsswitch:
NSS_ACTION_MERGE. To take advantage of it, one will add [SUCCESS=merge]
between two database entries in the nsswitch.conf file. When a group is
located in the first of the two group entries, processing will continue
on to the next one. If the group is also found in the next entry (and the
group name and GID are an exact match), the member list of the second
entry will be added to the group object to be returned.

== Implementation ==
After each DL_LOOKUP_FN() returns, the next action is checked. If the
function returned NSS_STATUS_SUCCESS and the next action is
NSS_ACTION_MERGE, a copy of the result buffer is saved for the next pass
through the loop. If on this next pass through the loop the database
returns another instance of a group matching both the group name and GID,
the member list is added to the previous list and it is returned as a
single object. If the following database does not contain the same group,
then the original is copied back into the destination buffer.

This patch implements merge functionality only for the group database.
For other databases, there is a default implementation that will return
the EINVAL errno if a merge is requested. The merge functionality can be
implemented for other databases at a later time if such is needed. Each
database must provide a unique implementation of the deep-copy and merge
functions.

If [SUCCESS=merge] is present in nsswitch.conf for a glibc version that
does not support it, glibc will process results up until that operation,
at which time it will return results if it has found them or else will
simply return an error. In practical terms, this ends up behaving like
the remainder of the nsswitch.conf line does not exist.

== Iterators ==
This feature does not modify the iterator functionality from its current
behavior. If getgrnam() or getgrgid() is called, glibc will iterate
through all entries in the `group` line in nsswitch.conf and display the
list of members without attempting to merge them. This is consistent with
the behavior of nss_files where if two separate lines are specified for
the same group in /etc/groups, getgrnam()/getgrgid() will display both.
Clients are already expected to handle this gracefully.

== No Premature Optimizations ==
The following is a list of places that might be eligible for
optimization, but were not overengineered for this initial contribution:
 * Any situation where a merge may occur will result in one malloc() of
   the same size as the input buffer.
 * Any situation where a merge does occur will result in a second
   malloc() to hold the list of pointers to member name strings.
 * The list of members is simply concatenated together and is not tested
   for uniqueness (which is identical to the behavior for nss_files,
   which will simply return identical values if they both exist on the
   line in the file. This could potentially be optimized to reduce space
   usage in the buffer, but it is both complex and computationally
   expensive to do so.

== Testing ==
I performed testing by running the getent utility against my newly-built
glibc and configuring /etc/nsswitch.conf with the following entry:
group: group:      files [SUCCESS=merge] sss

In /etc/group I included the line:
wheel:x:10:sgallagh

I then configured my local SSSD using the id_provider=local to respond
with:
wheel:*:10:localuser,localuser2

I then ran `getent group wheel` against the newly-built glibc in
multiple situations and received the expected output as described
above:
 * When SSSD was running.
 * When SSSD was configured in nsswitch.conf but the daemon was not
   running.
 * When SSSD was configured in nsswitch.conf but nss_sss.so.2 was not
   installed on the system.
 * When the order of 'sss' and 'files' was reversed.
 * All of the above with the [SUCCESS=merge] removed (to ensure no
   regressions).
 * All of the above with `getent group 10`.
 * All of the above with `getent group` with and without
   `enumerate=true` set in SSSD.
 * All of the above with and without nscd enabled on the system.

1 files changed, 24 insertions, 3 deletions

diff --git a/nss/getnssent_r.c b/nss/getnssent_r.c
index 456907b018..f5092482ef 100644
--- a/nss/getnssent_r.c
+++ b/nss/getnssent_r.c
@@ -79,7 +79,18 @@ __nss_setent (const char *func_name, db_lookup_function lookup_fct,
       else
 	status = DL_CALL_FCT (fct.f, (0));
 
-      no_more = __nss_next2 (nip, func_name, NULL, &fct.ptr, status, 0);
+
+      /* This is a special-case.  When [SUCCESS=merge] is in play,
+         _nss_next2() will skip to the next database.  Due to the
+         implementation of that function, we can't know whether we're
+         in an enumeration or an individual lookup, which behaves
+         differently with regards to merging.  We'll treat SUCCESS as
+         an indication to start the enumeration at this database. */
+      if (nss_next_action (*nip, status) == NSS_ACTION_MERGE)
+	no_more = 1;
+      else
+	no_more = __nss_next2 (nip, func_name, NULL, &fct.ptr, status, 0);
+
       if (is_last_nip)
 	*last_nip = *nip;
     }
@@ -175,8 +186,18 @@ __nss_getent_r (const char *getent_func_name,
 
       do
 	{
-	  no_more = __nss_next2 (nip, getent_func_name, NULL, &fct.ptr,
-				 status, 0);
+        /* This is a special-case.  When [SUCCESS=merge] is in play,
+           _nss_next2() will skip to the next database.  Due to the
+           implementation of that function, we can't know whether we're
+           in an enumeration or an individual lookup, which behaves
+           differently with regards to merging.  We'll treat SUCCESS as
+           an indication to return the results here. */
+	  if (status == NSS_STATUS_SUCCESS
+	      && nss_next_action (*nip, status) == NSS_ACTION_MERGE)
+	    no_more = 1;
+	  else
+	    no_more = __nss_next2 (nip, getent_func_name, NULL, &fct.ptr,
+				   status, 0);
 
 	  if (is_last_nip)
 	    *last_nip = *nip;