Bug 745675

Summary: Group membership/access not working properly with glibc-2.14.90-11
Product: [Fedora] Fedora Reporter: Jason Montleon <jmontleo>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: urgent    
Version: 16CC: agrover, ahmadsamir3891, akozumpl, alekcejk, anton, artemy.kapitula, atu, barry_fishman, bojan, bruno, bugsgentoo, debarshir, desrt, erinn.looneytriggs, fabian.deutsch, fdaluisio, gholms, info, jakub, jik, jonh.wendell, justin.brown1.1, maciek.borzecki, mads, mgoldman, mhlavink, misek, mishu, mschmidt, mteixeira, pbrobinson, PTrenholme, rebus, richardfearn, samuel-rhbugs, s.binnie, schwab, scottro11, shenson, tmraz, zeekec
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=745661
https://bugzilla.redhat.com/show_bug.cgi?id=746051
Whiteboard:
Fixed In Version: glibc-2.14.90-12.999 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 745661 (view as bug list) Environment:
Last Closed: 2011-10-19 00:33:50 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 713568    
Attachments:
Description Flags
nsswitch.conf from my system none

Description Jason Montleon 2011-10-12 21:36:42 EDT
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.
Comment 1 Michal Ambroz 2011-10-12 22:18:37 EDT
*** Bug 745661 has been marked as a duplicate of this bug. ***
Comment 2 Fabian Deutsch 2011-10-13 10:22:50 EDT
*** Bug 745798 has been marked as a duplicate of this bug. ***
Comment 3 Fabian Deutsch 2011-10-13 10:23:05 EDT
*** Bug 745778 has been marked as a duplicate of this bug. ***
Comment 4 Ondrej Vasik 2011-10-13 16:01:30 EDT
*** Bug 746002 has been marked as a duplicate of this bug. ***
Comment 5 Marek Goldmann 2011-10-14 03:55:09 EDT
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.
Comment 6 Marek Goldmann 2011-10-14 04:14:16 EDT
(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.
Comment 7 Tomas Mraz 2011-10-14 07:22:22 EDT
*** Bug 746210 has been marked as a duplicate of this bug. ***
Comment 8 Scott Robbins 2011-10-14 07:55:13 EDT
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.
Comment 9 Simon Binnie 2011-10-14 08:19:21 EDT
(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).
Comment 10 Scott Robbins 2011-10-14 08:28:48 EDT
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.
Comment 11 Erinn Looney-Triggs 2011-10-14 09:27:16 EDT
*** Bug 746051 has been marked as a duplicate of this bug. ***
Comment 12 Andreas Schwab 2011-10-14 09:34:10 EDT
I cannot reproduce that.  What is your NSS configuration?
Comment 13 Jason Montleon 2011-10-14 09:56:59 EDT
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.
Comment 14 Scott Robbins 2011-10-14 10:20:55 EDT
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.
Comment 15 Scott J Henson 2011-10-14 23:32:04 EDT
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.
Comment 16 Jakub Jelinek 2011-10-15 03:26:59 EDT
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, &notfound, 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.
Comment 17 Jakub Jelinek 2011-10-15 03:36:26 EDT
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).
Comment 18 Ondrej Vasik 2011-10-15 08:37:43 EDT
*** Bug 746386 has been marked as a duplicate of this bug. ***
Comment 19 Jonh Wendell 2011-10-15 09:53:33 EDT
jakub, both programs just print '1000' on the output. (which is my gid)
Comment 20 Peter Robinson 2011-10-16 04:35:42 EDT
I'm seeing this on some machines and not others. Not sure what the correlation is.

Adding as a blocker
Comment 21 Artemy Kapitula, RCNTEC Ltd 2011-10-16 06:09:04 EDT
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)

!!!!
Comment 22 Jason Montleon 2011-10-16 12:19:22 EDT
Updated to 2.14.90-12 and the issue remains.
Comment 23 Michal Ambroz 2011-10-16 18:30:48 EDT
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
Comment 24 Nils Philippsen 2011-10-17 06:09:55 EDT
*** Bug 746360 has been marked as a duplicate of this bug. ***
Comment 25 Fedora Update System 2011-10-17 09:32:49 EDT
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
Comment 26 Jason Montleon 2011-10-17 09:52:57 EDT
2.14.90-12.999 corrects the issue for me.
Comment 27 Scott Robbins 2011-10-17 10:47:57 EDT
It corrects it for me as well.
Comment 28 Kevin Fenzi 2011-10-17 16:25:50 EDT
*** Bug 746684 has been marked as a duplicate of this bug. ***
Comment 29 Fedora Update System 2011-10-18 03:22:12 EDT
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).
Comment 30 Francesco 2011-10-18 04:31:38 EDT
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
Comment 31 Artemy Kapitula, RCNTEC Ltd 2011-10-18 05:41:55 EDT
Yea, it's fixed for me now too.
Comment 32 Michal Hlavinka 2011-10-18 08:54:02 EDT
*** Bug 746505 has been marked as a duplicate of this bug. ***
Comment 33 Fedora Update System 2011-10-19 00:33:50 EDT
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.
Comment 34 Justin Brown 2011-10-24 13:09:05 EDT
*** Bug 748314 has been marked as a duplicate of this bug. ***