Cloned for glibc as requested by Tomas. +++ This bug was initially created as a clone of Bug #750388 +++ Description of problem: In Fedora 16, users' secondary groups are not being populated correctly. If a user runs "groups", only the primary group appears. Version-Release number of selected component (if applicable): sssd-1.6.2-5.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Only the first group appears. Expected results: Groups should list all groups, not just the first group. Additional info: The backend is LDAP. The groups work correctly in Fedora 15 with the exact same configuration files and using the exact same LDAP server. What other information would be helpful? Thanks. --- Additional comment from jhrozek on 2011-11-01 05:19:36 EDT --- (In reply to comment #0) > What other information would be helpful? Thanks. Debug logs. Please add "debug_level=10" to the domain section of sssd.conf, restart sssd and then attach /var/log/sssd/sssd_domain.log --- Additional comment from sgallagh on 2011-11-01 07:16:02 EDT --- I'd also like to see your (sanitized) sssd.conf and a little information about your LDAP layout. --- Additional comment from amcnabb on 2011-11-01 11:24:17 EDT --- Created attachment 531151 [details] sssd_LDAP.log I'm attaching sssd_LDAP.log with debug_level set to 10. By the way, the groups "wheel" and "guest" are both groups that the "amcnabb" user should be a member of. --- Additional comment from amcnabb on 2011-11-01 11:25:53 EDT --- Created attachment 531152 [details] sssd.conf --- Additional comment from amcnabb on 2011-11-01 11:30:38 EDT --- (In reply to comment #2) > I'd also like to see your (sanitized) sssd.conf and a little information about > your LDAP layout. Our users are in ou=people,dc=aml,dc=cs,dc=byu,dc=edu and our groups are in ou=group,dc=aml,dc=cs,dc=byu,dc=edu. The wheel group is cn=wheel,ou=group,dc=aml,dc=cs,dc=byu,dc=edu. The ldif for the wheel group is: """ dn: cn=wheel cn: wheel gidNumber: 9999 objectClass: posixGroup objectClass: top structuralObjectClass: posixGroup memberUid: root memberUid: amcnabb """ (with some additional memberUid entries) The "guest" group is much the same, except its gid is 10001. I'm not sure if this is the sort of LDAP layout information that you're looking for, so feel free to ask any additional questions. --- Additional comment from sgallagh on 2011-11-01 11:37:59 EDT --- Could you try setting 'enumerate = false', deleting/backing up your /var/lib/sss/db/cache_LDAP.ldb file and restarting SSSD? I'd like to know if there might be a bug in the enumeration code that's causing your group memberships to disappear. We mostly test with enumerate=false, because in most environments it's much faster (which is why it's the default) --- Additional comment from amcnabb on 2011-11-01 11:44:12 EDT --- Setting "enumerate=false" and deleting cache_LDAP.ldb doesn't seem to have made any difference. (We only have about 25 users, so presumably enumerate=true shouldn't be slow.) --- Additional comment from sgallagh on 2011-11-01 11:52:50 EDT --- What happens if you do: 'getent group wheel' Do you get the correct set of users back? --- Additional comment from amcnabb on 2011-11-01 11:58:01 EDT --- Yes, "getent group wheel" gives the correct set of users. --- Additional comment from sgallagh on 2011-11-01 13:37:33 EDT --- Andrew, what version of glibc do you have on the system? rpm -q glibc --- Additional comment from amcnabb on 2011-11-01 14:06:30 EDT --- glibc-2.14.90-14.x86_64 --- Additional comment from amcnabb on 2011-11-03 11:46:36 EDT --- I noticed today that PolicyKit successfully finds the members of the wheel group (polkit is configured with "AdminIdentities=unix-group:wheel"). It's interesting that both polkit and "getent group wheel" work. Is there anything else that I should try to help track down the problem? --- Additional comment from sgallagh on 2011-11-04 12:24:00 EDT --- (In reply to comment #12) > I noticed today that PolicyKit successfully finds the members of the wheel > group (polkit is configured with "AdminIdentities=unix-group:wheel"). It's > interesting that both polkit and "getent group wheel" work. > > Is there anything else that I should try to help track down the problem? Does the 'wheel' group also exist in /etc/groups? --- Additional comment from amcnabb on 2011-11-04 12:44:57 EDT --- No--our postinstall script removes it to make sure that there's no conflict. --- Additional comment from amcnabb on 2011-11-04 12:55:35 EDT --- Created attachment 531809 [details] output from ldbsearch I saw an older bug where the reporter was asked to run ldbsearch. I don't know if the information is helpful here, but I'll attach it just in case. I generated the attachment by running the following: # ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb |grep -i -v pass >~amcnabb/tmp/ldbsearch.txt asq: Unable to register control with rootdse! # The only interesting thing I noticed in the output was that in the record for amcnabb, it correctly included "memberof: name=guest,cn=groups,cn=LDAP,cn=sysdb" and "memberof: name=wheel,cn=groups,cn=LDAP,cn=sysdb". --- Additional comment from sgallagh on 2011-11-04 13:05:16 EDT --- Andrew, what output do you get from 'id amcnabb' I saw someone else reporting earlier today that 'groups' was missing groups for them too, but 'id username' had everything correct. If so, I think this is actually a glibc bug, not an SSSD bug. Your LDB date looks perfect, so there's no reason it should not be reporting correctly. --- Additional comment from amcnabb on 2011-11-04 13:08:40 EDT --- Unfortunately, id is also showing incomplete information: # id amcnabb uid=10005(amcnabb) gid=10000(aml) groups=10000(aml) # --- Additional comment from amcnabb on 2011-11-04 13:13:40 EDT --- I found it! It turns out that the following was in nsswitch.conf: passwd: files sss shadow: files sss group: files sss initgroups: files When I switched the last line to: initgroups: files sss it started working. I'm thinking this might be an authconfig or anaconda bug. --- Additional comment from sgallagh on 2011-11-04 13:15:53 EDT --- (In reply to comment #18) > When I switched the last line to: > > initgroups: files sss What the heck? When did they add an 'initgroups' line? That's definitely new... Yeah, if that's being added by default now, we need to have authconfig make sure to handle this. If you remove that line completely (or comment it out) do things work again? --- Additional comment from amcnabb on 2011-11-04 13:21:09 EDT --- (In reply to comment #19) > What the heck? When did they add an 'initgroups' line? That's definitely new... That's what I thought. :) > Yeah, if that's being added by default now, we need to have authconfig make > sure to handle this. > > If you remove that line completely (or comment it out) do things work again? If I comment out the line, it works correctly. --- Additional comment from amcnabb on 2011-11-04 13:24:31 EDT --- So is this a glibc bug for including an unnecessary line that complicates life in the standard nsswitch.conf, or is it a authconfig bug for not writing the new initgroups line? Also, this should probably be documented in the Fedora 16 Release Notes, right? --- Additional comment from sgallagh on 2011-11-04 13:26:25 EDT --- Thanks for your patience and help in working this out. It looks like this is something new that glibc added in F16 without advertising, and it's breaking any non-files-based deployments on Fedora, because authconfig doesn't know to update it. I'm going to reassign this to authconfig. --- Additional comment from amcnabb on 2011-11-04 13:30:24 EDT --- I'm glad I could help. For now, I'm just removing the initgroups line in my postinstall because I can't think of any reason that it would be helpful to have initgroups be defined separately from groups. --- Additional comment from tmraz on 2011-11-04 14:02:28 EDT --- To me it seems like default nsswitch.conf from glibc should have it simply commented out if in this case the value is copied from the groups value. I can certainly add the patch to authconfig to support it - it will be trivial. However such a change without any heads up notice is really not nice from glibc. --- Additional comment from amcnabb on 2011-11-04 14:17:46 EDT --- (In reply to comment #24) > I can certainly add the patch to authconfig to support it - it will be trivial. > However such a change without any heads up notice is really not nice from > glibc. Indeed. Is there anyone in particular from glic that should be cc'ed on this bug? --- Additional comment from tmraz on 2011-11-04 14:49:27 EDT --- Please clone this bug for glibc component.
1. The addition of initgroups entry into nsswitch.conf should have been properly announced. 2. For backwards compatibility it should be commented out in the default nsswitch.conf
Andreas can you please explain what this initgroups is ? Also can we please prepare an update to push right after GA to back this change out ? *IF* there is a good reason to have an option like this it must: A) be discussed widly with stakeholders (at least the main nss_* modules maintainers) B) Be backwards compabible *BY DEFAULT* I am too angry to better articulate any request, but a prompt discussion about this *feature* is highly desirable.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
glibc-2.14.90-15.1 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/glibc-2.14.90-15.1
Package glibc-2.14.90-15.1: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-15.1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15723 then log in and leave karma (feedback).
Package glibc-2.14.90-15.2: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-15.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15723 then log in and leave karma (feedback).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Package glibc-2.14.90-16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15723 then log in and leave karma (feedback).
glibc-2.14.90-18 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/glibc-2.14.90-18
I still have a problem with secondary LDAP and local groups. I am now a member of my LDAP groups after updating to authconfig-6.1.16-2.fc16 and running "authconfig -updateall". However, if I add myself to any group in /etc/group, the result is that I am now only a member of the local groups and not any of the LDAP groups. /etc/nsswitch.conf (after applying authconfig-6.1.16-2.fc16 [bug 750388]): initgroups: files sss without "me" being a member of any group in /etc/group: $ groups me software security staff ftpadmin sysadmin adding me to a group in /etc/group apache:x:48:me $ groups me apache Removing the initgroups line from /etc/nsswitch.conf exhibits expected behavior, as reported above: $ groups me apache software security staff ftpadmin sysadmin
Robert, the correct configuration is to comment out initgroups entirely. Authconfig tries it's best to respect what the admin may have set, unfortunately the initgroups is simply terminally stupid and completely breaks any existing configfuration no matter what as it completely changes the semantics of the initgroups call. The glibc maintainer messed up badly and initgroups is enabled by default in F16 GA, so you may have to manually remove it.
If you remove the entry, authconfig will not readd it. Unfortunately the semantics of the initgroups is different from the other entries and authconfig will have to be changed to respect it. I really wonder whether it wouldn't be the best idea to always just remove the entry by authconfig.
Tomas, what about adding a authconfig option like --preserve-initgroups and otherwise always remove it ? In almost all cases you would never want to use initgroups as defined in glibc as it makes little to no sense.
I'm not sure if that would really make sense to have this option - basically if you want to modify the pam and nsswitch.conf files manually, you should not use the authconfig at all. So I'll probably remove the entry altogether and unconditionally. Hopefully glibc will keep the old backwards compatible semantics when the entry is not there in future.
Works for me.
I believe we still need a fix for this in glibc. AIUI the desired fix is for the initgroups line to be dropped entirely from the default /etc/nsswitch.conf file, right Tomas? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes, or it can be left there commented out with an appropriate comment about the semantic difference between initgroups entry and the other entries.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening since this bug still needs triaging and answering. Moving to rawhide to see if we can reproduce.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
The SSSD nss plugin already implements initgroups_dyn support, so I assume what initgroups is for is already known. It looks like the patch to remove the initgroups line from the default nsswitch.conf was committed to the fedora/master branch in the upstream glibc[1] repository but it was never pulled into Fedora. When we finally discovered the branches and their use (in 2013), I did not notice this until I came across this bug. If the sssd initgroups_dyn callback is an optimal implementation for initgroups (i.e. it is faster than just using groups as fallback), then it might make sense to keep the initgroups line in place like this: initgroups: files [SUCCESS=continue] sss authconfig will then have to support this. The files implementation for initgroups is not really any better than groups AFAIR, so the only other benefits of initgroups are visible when one uses nscd (not default) or uses the nssdb (again, not default). If it doesn't matter, I'll just remove the line from nsswitch. Let me know what is preferable. [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3b819160
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
(In reply to Siddhesh Poyarekar from comment #23) > If it doesn't matter, I'll just remove the line from nsswitch. Let me know > what is preferable. Ping?
I'd say just remove it.
Pushed in rawhide and I've also got an f23 build going.
glibc-2.22-2.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/glibc-2.22-2.fc23
Package glibc-2.22-2.fc23: * should fix your issue, * was pushed to the Fedora 23 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.22-2.fc23' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-13713/glibc-2.22-2.fc23 then log in and leave karma (feedback).
glibc-2.22-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.