1 Commits

Author	SHA1	Message	Date
Stephen Gallagher	ced8f89336	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❌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.	2016-04-29 22:18:21 -04:00