Description of problem:
By default, recent versions of glibc add a new line to /etc/nsswitch.conf for specifying search order for initgroups requests. This is a complete semantic break from existing systems (and the new semantics make it impossible to configure a system for useres to have both central and local group assignments).
This needs to be reverted immediately.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure a system to get its users and group information from SSSD (or nss_ldap, or nss_nis, etc.)
2. Add the following line to /etc/nsswitch.conf:
initgroups: files sss
3. Run the command 'id -G <user_in_sssd>'
If the group is a member of any local groups, only those will be returned. If not, their groups served by SSSD are returned.
All the groups that the user belongs to, both local and remote, must be returned.
With debug logs enabled, I can confirm that glibc never tries to ask SSSD to respond with its groups if some have been found in 'files'. Reversing the order in the initgroups: line means that I see only network groups and zero local groups.
The previous behavior of libc was to search every database listed in the groups: line for groups that this user belonged to and return them. This behavior is still available if the initgroups: line is deleted or commented out from nsswitch.conf, but it is present by default, which is unacceptable.
I propose the following options:
1) Drop this initgroups: line entirely and revert to the older (and well-understood) behavior.
2) Retain the initgroups: line but ensure that ALL entries specified in it are searched (in order). The search should not stop at the first match.
I believe glibc is behaving per its specifications with regard to the behaviour when the requested entry is found. ie, when the requested entry is found, the default behaviour is to stop searching.
I believe the behaviour you want is achieved by this configuration:
initgroups: files [SUCCESS=continue] sss
Reopening and reassigning to authconfig. The default behavior of the initgroups: line is unusable for any deployment relying on central users as I explained above. We need to ensure that when configuring SSSD (and LDAP, and NIS...) that we add [SUCCESS=continue] to unbreak support for using both local and remote groups with remote users.
So glibc started to put the 'initgroups: files' line into the /etc/nsswitch.conf without any heads up in Fedora 17? Nice change. :(
Welcome to the past, this is just https://bugzilla.redhat.com/show_bug.cgi?id=751450 all over ...
Yes, I know, I'd just expect some heads up before that entry was readded back.
Me personally, I'd expect an entry that's used to set a user's grouplist to show up in the manpage.
Silly, I know...
James, please open another bug report for this request against the man-pages package.
Authconfig currently just comments the initgroups: line out when it is updating nsswitch.conf. Is that a problem? Or glibc now requires the line and the initgroups behavior is broken without it?
Jeff, please answer my question above. Is the behaviour of glibc the same as in old releases if I just comment out the initgroups line in nsswitch.conf? As that is what authconfig does currently. Or do I have to explicitly configure the initgroups line for the initgroups() call to work fine with both local and remote groups.
Sorry, I must have missed the BZ notification for c#8.
As far as I know, commenting out the initgroups line should safe and should cause glibc to fall back to its prior behaviour.
However, this is a part of glibc I know very very little about; so it'd be best if you could verify you're getting the behaviour you want when you eliminate that line rather than blindly assuming my reading of the code is correct.