Description of problem: With the following: glibc-2.14.90-10.x86_64 glibc-common-2.14.90-10.x86_64 glibc-headers-2.14.90-10.x86_64 glibc-devel-2.14.90-10.x86_64 glibc-2.14.90-10.i686 id jmontleo uid=13693(jmontleo) gid=13693(jmontleo) groups=13693(jmontleo),13694(libvirt) updating to: glibc-common-2.14.90-11.x86_64 glibc-2.14.90-11.x86_64 glibc-headers-2.14.90-11.x86_64 glibc-devel-2.14.90-11.x86_64 glibc-2.14.90-11.i686 id jmontleo uid=13693(jmontleo) gid=13693(jmontleo) groups=13693(jmontleo) Group membership has not been modified and downgrading gets it working again. This seems to be affecting other aspects of group membership as well, besides the id command, since my membership in the libvirt group is not being acknowledged when I try to start the Virtual Machine Manager: ls -al /var/run/libvirt/libvirt-sock srwxrwx---. 1 root libvirt 0 Oct 12 21:07 /var/run/libvirt/libvirt-sock touch /var/run/libvirt/libvirt-sock touch: cannot touch `/var/run/libvirt/libvirt-sock': Permission denied Version-Release number of selected component (if applicable): glibc-common-2.14.90-11 How reproducible: Always Steps to Reproduce: 1. Add a new group 2. Add yourself to the group 3. Upgrade glibc to the latest Actual results: Notice that your group memberships are not working Expected results: Group membership should be working as expected. Additional info: Note some things, like the id command, seem to be affected immediately, others don't break (or get fixed with a downgrade) until you reboot.
*** Bug 745661 has been marked as a duplicate of this bug. ***
*** Bug 745798 has been marked as a duplicate of this bug. ***
*** Bug 745778 has been marked as a duplicate of this bug. ***
*** Bug 746002 has been marked as a duplicate of this bug. ***
I've downgraded glibc per suggestion, but regular user is not aware of the group names: [goldmann@nightmare ~]$ id uid=1000(goldmann) gid=1000 groups=1000,10 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [goldmann@nightmare ~]$ groups groups: cannot find name for group ID 1000 1000 groups: cannot find name for group ID 10 10 Whereas root is fine with it: [root@nightmare ~]# id goldmann uid=1000(goldmann) gid=1000(goldmann) groups=1000(goldmann),10(wheel) FYI: I rebooted my box after downgrade.
(In reply to comment #5) > I've downgraded glibc per suggestion, but regular user is not aware of the > group names: Found my issue - somehow /etc/group file permission was changed to 600 which prevented reading the names of the groups. Not sure if this is related with the glibc downgrade though.
*** Bug 746210 has been marked as a duplicate of this bug. ***
The group file permissions aren't fixing it for me. Although they're 644, doing groups <username> only shows the original group, not others, such as wheel or audio.
(In reply to comment #8) > The group file permissions aren't fixing it for me. Although they're 644, > doing groups <username> only shows the original group, not others, such as > wheel or audio. Have you also downgraded the glibc packages stated in the initial report? The permissions issue was something that might crop up after the downgrade (it's not in itself a workaround for the bug).
No, I've left it alone, figuring it will be fixed shortly, as I have workarounds for the two memberships (wheel and audio) that cause me problems.
*** Bug 746051 has been marked as a duplicate of this bug. ***
I cannot reproduce that. What is your NSS configuration?
Created attachment 528208 [details] nsswitch.conf from my system I have not manually edited the file, so it should be a pretty much default nsswitch.conf from a Fedora 16 system.
I use ldap and winbind as well. However, replacing it with an nsswitch.conf that just had files for password, group, and shadow, then rebooting, didn't fix the problem.
Correct permissions on my install, but my user does not seem to be in the wheel group anymore, thus sudo is broken. Also the following tidbits. [root@aiden ~]# id scott uid=1000(scott) gid=1000(scott) groups=1000(scott) [root@aiden ~]# getent group wheel wheel:x:10:scott [root@aiden ~]# groups scott scott : scott My user gets the same result. It can tell that I'm in the group when I use getent, but nothing else, including sudo, seems to be able to figure out that fact. One big thing, I had to reboot to reproduce this issue. I tried reproducing it after an upgrade after discussing it with Jason, but things were acting appropriately. Post reboot, I can reproduce all the same issues he was having. My nsswitch.conf contains the following pertinent lines: passwd: files shadow: files group: files Also, /etc/group has 644 permissions without me having to change or otherwise adjust.I tried putting selinux into permissive mode and got the same results.
Do you run nscd? If yes, can you retry after disabling nscd? Can you try if it is just initgroups that fails? As root run ./thistest scott (both with nscd running and without)? #include <errno.h> #include <error.h> #include <pwd.h> #include <grp.h> #include <stdio.h> #include <unistd.h> int main (int argc, const char **argv) { struct passwd *pwd = getpwnam (argv[1]); gid_t groups[64]; int i, n; if (pwd == NULL) error (1, errno, "getpwnam failed"); if (initgroups (pwd->pw_name, pwd->pw_gid) < 0) error (1, errno, "initgroups failed"); n = getgroups (64, groups); for (i = 0; i < n; i++) printf ("%d ", groups[i]); putchar ('\n'); return 0; } I see there have been netgroup changes for nscd, but unless you are using netgroups that should hopefully not affect this. There is the diff --git a/nscd/grpcache.c b/nscd/grpcache.c index 8a2f80c..e9607c6 100644 --- a/nscd/grpcache.c +++ b/nscd/grpcache.c @@ -117,6 +117,8 @@ cache_addgr (struct database_dyn *db, int fd, request_header *req, if (fd != -1) written = TEMP_FAILURE_RETRY (send (fd, ¬found, total, MSG_NOSIGNAL)); + else + written = total; /* If we cannot permanently store the result, so be it. */ if (db->negtimeout == 0) change, but it should affect just nscd and only the if (__builtin_expect (written != total, 0) && debug_level > 0) { char buf[256]; dbg_log (_("short write in %s: %s"), __FUNCTION__, strerror_r (errno, buf, sizeof (buf))); } verbose logging I'd say.
And/or: #include <errno.h> #include <error.h> #include <pwd.h> #include <grp.h> #include <stdio.h> #include <unistd.h> int main (int argc, const char **argv) { struct passwd *pwd = getpwnam (argv[1]); gid_t groups[64]; int i, n = 64; if (pwd == NULL) error (1, errno, "getpwnam failed"); if (getgrouplist (pwd->pw_name, pwd->pw_gid, groups, &n) < 0) error (1, errno, "getgrouplist failed"); for (i = 0; i < n; i++) printf ("%d ", groups[i]); putchar ('\n'); return 0; } (this one can be run as normal user).
*** Bug 746386 has been marked as a duplicate of this bug. ***
jakub, both programs just print '1000' on the output. (which is my gid)
I'm seeing this on some machines and not others. Not sure what the correlation is. Adding as a blocker
I confirm bug on my Fedora 16 x86-64. 1. The bug is reproduced with file-based users and group in /etc/{passwd|group} 2. I use SSSD, so the bug is reproduced for the users and groups from LDAP 3. newgrp command is working - when the user accounts affected by the bug can execute newgrp: Examine situation: [viking@book ~]$ cat /etc/passwd | grep viking viking:x:500:500::/home/viking:/bin/bash [viking@book ~]$ cat /etc/group | grep viking kvm:x:36:qemu,viking,kiki viking:x:500: we:x:503:kiki,viking [viking@book ~]$ id uid=500(viking) gid=500(viking) groups=500(viking) Use of newgrp: [viking@book ~]$ newgrp we [viking@book ~]$ id uid=500(viking) gid=503(we) groups=500(viking),503(we) [viking@book ~]$ newgrp qemu Password: Invalid password. [viking@book ~]$ newgrp kvm [viking@book ~]$ id uid=500(viking) gid=36(kvm) groups=500(viking),36(kvm),503(we) !!!!
Updated to 2.14.90-12 and the issue remains.
Just tried glibc-2.14.90-12 and the issue is not fixed (i686). $ rpm -qa|grep glibc glibc-devel-2.14.90-12.i686 glibc-debuginfo-2.14.90-12.i686 glibc-headers-2.14.90-12.i686 glibc-common-2.14.90-12.i686 glibc-static-2.14.90-12.i686 glibc-debuginfo-common-2.14.90-12.i686 glibc-utils-2.14.90-12.i686 glibc-2.14.90-12.i686 $ uname -a Linux mixer.localdomain 3.1.0-0.rc9.git0.0.fc16.i686.PAE #1 SMP Wed Oct 5 15:51:55 UTC 2011 i686 i686 i386 GNU/Linux $ grep wheel /etc/passwd $ grep wheel /etc/group wheel:x:10:root,mambroz $ id uid=1000(mambroz) gid=1000(mambroz) groups=1000(mambroz) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
*** Bug 746360 has been marked as a duplicate of this bug. ***
glibc-2.14.90-12.999 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/glibc-2.14.90-12.999
2.14.90-12.999 corrects the issue for me.
It corrects it for me as well.
*** Bug 746684 has been marked as a duplicate of this bug. ***
Package glibc-2.14.90-12.999: * 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-12.999' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14504 then log in and leave karma (feedback).
Package glibc-2.14.90-12 doesn't fix the issue, Package glibc-2.14.90-12.999: corrects the issue for me (746386 duplicate of 745675) thanks! > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2011-14504 > then log in and leave karma (feedback). karma +1
Yea, it's fixed for me now too.
*** Bug 746505 has been marked as a duplicate of this bug. ***
glibc-2.14.90-12.999 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 748314 has been marked as a duplicate of this bug. ***