Hide Forgot
Given a local groups.db file and db auth enabled in nsswitch.conf, large groups appear to cause getent to exit and stop processing groups. This may be a 4096 byte limit? Note that you can 'getent group name' and it works, just 'getent group' stops processing when it hits one of these. Users in any of these groups don't get secondary group membership on logging in. They can 'newgrp name' and that works. Adding one of the large groups to the local /etc/groups file does work fine, it's only when they are in the db that it fails. This may be related to: 745675 and/or 739360 but simply the db case instead of local group case. You can see this bug in action on my F16/rawhide test machines. See: http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers for access info. The 'ambassadors' group is the first group that hits this and it stops processing then. f15 handles this exact same setup just fine.
Please provide a test case.
Attaching an /etc/group file. on f16 when I add the 'wtf' group entries I get a segfault from glibc. I'll attach the trace info as well.
Created attachment 531807 [details] group file where things meltdown Take the bottom entries and put them in an /etc/group - add your username to the groups and try 'id yourusername' and see if it dies for you.;
dump out of glibc: *** glibc detected *** id: double free or corruption (!prev): 0x00000000024a1840 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3832a7c606] /lib64/libnss_files.so.2(_nss_files_initgroups_dyn+0x367)[0x7fb0f98518e7] /lib64/libc.so.6[0x3832ab803d] /lib64/libc.so.6(getgrouplist+0x64)[0x3832ab8284] id[0x402cf8] id[0x402e76] id[0x401b85] /lib64/libc.so.6(__libc_start_main+0xed)[0x3832a2169d] id[0x401dfd] ======= Memory map: ======== 00400000-00407000 r-xp 00000000 fd:00 45232 /usr/bin/id 00606000-00607000 r--p 00006000 fd:00 45232 /usr/bin/id 00607000-00608000 rw-p 00007000 fd:00 45232 /usr/bin/id 0248f000-024b0000 rw-p 00000000 00:00 0 [heap] 3832200000-3832222000 r-xp 00000000 fd:00 71760 /lib64/ld-2.14.90.so 3832421000-3832422000 r--p 00021000 fd:00 71760 /lib64/ld-2.14.90.so 3832422000-3832423000 rw-p 00022000 fd:00 71760 /lib64/ld-2.14.90.so 3832423000-3832424000 rw-p 00000000 00:00 0 3832a00000-3832baa000 r-xp 00000000 fd:00 71761 /lib64/libc-2.14.90.so 3832baa000-3832daa000 ---p 001aa000 fd:00 71761 /lib64/libc-2.14.90.so 3832daa000-3832dae000 r--p 001aa000 fd:00 71761 /lib64/libc-2.14.90.so 3832dae000-3832db0000 rw-p 001ae000 fd:00 71761 /lib64/libc-2.14.90.so 3832db0000-3832db5000 rw-p 00000000 00:00 0 3832e00000-3832e02000 r-xp 00000000 fd:00 71768 /lib64/libdl-2.14.90.so 3832e02000-3833002000 ---p 00002000 fd:00 71768 /lib64/libdl-2.14.90.so 3833002000-3833003000 r--p 00002000 fd:00 71768 /lib64/libdl-2.14.90.so 3833003000-3833004000 rw-p 00003000 fd:00 71768 /lib64/libdl-2.14.90.so 3833a00000-3833a15000 r-xp 00000000 fd:00 71778 /lib64/libgcc_s-4.6.2-20111027.so.1 3833a15000-3833c14000 ---p 00015000 fd:00 71778 /lib64/libgcc_s-4.6.2-20111027.so.1 3833c14000-3833c15000 rw-p 00014000 fd:00 71778 /lib64/libgcc_s-4.6.2-20111027.so.1 3834200000-383421d000 r-xp 00000000 fd:00 71771 /lib64/libselinux.so.1 383421d000-383441c000 ---p 0001d000 fd:00 71771 /lib64/libselinux.so.1 383441c000-383441d000 r--p 0001c000 fd:00 71771 /lib64/libselinux.so.1 383441d000-383441e000 rw-p 0001d000 fd:00 71771 /lib64/libselinux.so.1 383441e000-383441f000 rw-p 00000000 00:00 0 7fb0f9848000-7fb0f9854000 r-xp 00000000 fd:00 4724 /lib64/libnss_files-2.14.90.so 7fb0f9854000-7fb0f9a53000 ---p 0000c000 fd:00 4724 /lib64/libnss_files-2.14.90.so 7fb0f9a53000-7fb0f9a54000 r--p 0000b000 fd:00 4724 /lib64/libnss_files-2.14.90.so 7fb0f9a54000-7fb0f9a55000 rw-p 0000c000 fd:00 4724 /lib64/libnss_files-2.14.90.so 7fb0f9a55000-7fb0ffe78000 r--p 00000000 fd:00 5014 /usr/lib/locale/locale-archive 7fb0ffe78000-7fb0ffe7b000 rw-p 00000000 00:00 0 7fb0ffe8e000-7fb0ffe92000 rw-p 00000000 00:00 0 7fff3ff53000-7fff3ff74000 rw-p 00000000 00:00 0 [stack] 7fff3ffff000-7fff40000000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] uid=1001(skvidal) gid=1001(skvidal)Aborted (core dumped)
Additionally, for the db case, you can login to the test machines above and see it in action. Use your fedora ssh key, packagers have sudo. I can work on making a groups.db to attach here if you prefer, or just upload the one from those. In the db case it just doesn't show the groups, if you move them to /etc/groups, it looks like it crashes. ;(
doing more digging group with 4096 members works fine group with 4097 members causes the segfault. The members do NOT have to be unique - just put 4096 entries in there then add one to it - segfault.
-- 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
The update seems to fix the case of local groups > 4096 causing a segfault. However, it doesn't seem to address the db groups not appearing in getent group or populating users secondary groups on login.
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
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 issue to verify that the secondary groups problem is actually fixed. Moving to rawhide.
It's not that I can see. nssdb groups still don't setup right on login. :( Happy to help provide any further info on this or test fixes.
(In reply to comment #19) > It's not that I can see. > > nssdb groups still don't setup right on login. :( > > Happy to help provide any further info on this or test fixes. Thanks Kevin, I'll contact you when we get to the point of triaging this issue.
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
Just to note that this issue is still present in f17, f18, f19 and rawhide. ;) All the test machines in comment 1 show the issue (they are accessable by Fedora packagers)
Is there any information we can provide here to help track this down? It's anoying to have to run 'newgrp' all the time to get groups you should be in on login. ;( Happy to test fixes or gather more info, just let me know.
This still affects f19/f20/rawhide. Additionally it also affects rhel7. ;( This was fixed back in rhel6.1 in the seperate nssdb... perhaps that change could be cherry picked into the in glibc one? See https://bugzilla.redhat.com/show_bug.cgi?id=788668 for the rhel6.1 update.
The format fo the db file on the test systems is different; it does not have the initgroups entries at all. Assuming that it is generated regularly to include new contributors, what box is it generated on? It's likely that the file is generated on an old glibc version, or one that does not have this fix: commit 98591e582047b308de2ed0621088edad5d3cdf8a Author: Andreas Schwab <schwab> Date: Fri Nov 11 14:43:36 2011 +0100 Fix db makefile rule for group.db Could you try regenerating a new db file and then seeing if it works correctly? For completeness, I did test on a fresh rawhide box and was unable to reproduce the problem with large groups. All groups turn up correctly for me on rawhide.
Ah ha. This now looks like a bug in our fas code. ;( It's just calling makedb, without the format required. I will see about getting it fixed there. Thanks a lot for looking into it and pointing the right direction!
Cool, I'll close this as NOTABUG then.