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.
(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
I'd also like to see your (sanitized) sssd.conf and a little information about your LDAP layout.
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.
Created attachment 531152 [details] sssd.conf
(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.
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)
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.)
What happens if you do: 'getent group wheel' Do you get the correct set of users back?
Yes, "getent group wheel" gives the correct set of users.
Andrew, what version of glibc do you have on the system? rpm -q glibc
glibc-2.14.90-14.x86_64
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?
(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?
No--our postinstall script removes it to make sure that there's no conflict.
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".
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.
Unfortunately, id is also showing incomplete information: # id amcnabb uid=10005(amcnabb) gid=10000(aml) groups=10000(aml) #
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.
(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?
(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.
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?
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.
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.
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.
(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?
Please clone this bug for glibc component.
Yeah, we should definitely note this. sigh, glibc. So, for a layman, what exactly is the impact of this bug? When using a non-file backend for user accounts, secondary groups don't work right? Fix is to edit nsswitch.conf ? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #27) > Yeah, we should definitely note this. sigh, glibc. > > So, for a layman, what exactly is the impact of this bug? When using a non-file > backend for user accounts, secondary groups don't work right? Exactly. > Fix is to edit nsswitch.conf ? The easiest fix is to remove the "initgroups" line from nsswitch.conf. It might be possible to fix by upgrading to a hypothetical new glibc RPM, but I'm not sure if this is feasible once authconfig has modified the file.
Not only it is the easiest thing to remove the initgroups line. It is also the correct thing to do. The initgroups configuration option completely changes the behaviour of glibc wrt secondary groups. It is a clean break of what admins and user expect (whether the original behaviour was sane or not doesn't matter any more). The init groups line should be commented out and a prominent comment guarding against enabling it unless you *really* know what you are doing should be added to nsswitch.conf file. I am not sure how to unbreak existing installations, but I strongly believe extra work needs to be done to unbreak F16 machines with a 0 day update even if that means adding some nasty ugly post install scriplet.
(In reply to comment #29) > The initgroups configuration option completely changes the behaviour of glibc > wrt secondary groups. It is a clean break of what admins and user expect > (whether the original behaviour was sane or not doesn't matter any more). By the way, I couldn't find any documentation about how the behavior of glibc changes with this option. In fact, I opened bug #751429 earlier because this option is not listed in the nsswitch.conf(5) man page.
I guess this is informative: """Together with a previous patch which introduced the initgroups entry in nsswitch.conf this patch allows more customization of the lookups for initgroups/getgrouplist. Nothing changes if the groups entry in nsswitch.conf is used. If the initgroups entry is used instead the code now doesn't automatically continue looking for more entries aftedr a successful lookup. Instead the normal rules are followed which do specify that by default no more service is consulted. This can be overwritten with [SUCCESS=continue] appropriately placed in the line.""" http://sopc.et.ntust.edu.tw/?p=glibc.git;a=patch;h=7b3b0b2a63f7e980adb630550c0dc9639ec09d7f That really does sound like a dangerous change in behavior.
If we ship a 0-day update to fix this, then at least any *network* install of F16 should be safe, as it will have the fixed nsswitch.conf from day #1. It does sound like it might be a good idea to try and fix installed systems also, though it might be tricky. can someone file a new bug for glibc and post the URL here? thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The glibc bug clone is bug 751450
And the authconfig build that handles the initgroups entry is here: http://koji.fedoraproject.org/koji/buildinfo?buildID=272429 Note that authconfig will not add or uncomment the initgroups entry if it is not there. It will just add sssd or ldap to it if it is present.
note for future reference: when I say "if we ship a zero-day update to fix this" it can be taken as a kind of hint that it would be nice for someone to submit a zero-day update. the authconfig build referred to has not yet been _submitted_ as an update, much less accepted and pushed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I thought that the zero-day update would be in glibc.
authconfig-6.1.16-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/authconfig-6.1.16-2.fc16
(In reply to comment #36) > I thought that the zero-day update would be in glibc. Agreed. It's nice that authconfig can deal with this, but glibc is where the time-critical fix really needs to happen.
Package authconfig-6.1.16-2.fc16: * 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 authconfig-6.1.16-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15563 then log in and leave karma (feedback).
I don't really care who fixes what, I was just kind of expecting anyone who could fix anything would recognize the importance of doing so quickly... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
authconfig-6.1.16-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.