RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1809489 - python3 grp library functions grp.getgrnam() & grp.getgrgid() returning incorrect gr_mem information
Summary: python3 grp library functions grp.getgrnam() & grp.getgrgid() returning incor...
Keywords:
Status: CLOSED DUPLICATE of bug 1794607
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.1
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: 8.3
Assignee: SSSD Maintainers
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks: 1776265
TreeView+ depends on / blocked
 
Reported: 2020-03-03 09:00 UTC by Abhishek
Modified: 2020-04-28 11:27 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-12 10:52:19 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 185636 0 None None None 2020-04-28 11:27:26 UTC

Description Abhishek 2020-03-03 09:00:48 UTC 
Description of problem:
If root user is part of a linux group, then in the response of grp.getgrnam() & grp.getgrid(), in the gr_mem part, root user is not listed.

This is happening specifically in rhel 8 & above. In rhel 7.X, with python2, this bug was not there (in other OS, this works with python3).

Version-Release number of selected component (if applicable):

[root@xxyyzz ~]# cat /proc/version
Linux version 4.18.0-147.el8.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Thu Sep 26 15:52:44 UTC 2019

[root@xxyyzz ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.1 (Ootpa)

How reproducible:

By running grp.getgrnam() in python3 prompt

Steps to Reproduce:

In this example, linux group 'starwars' has 2 users, 'root' & 'abhi'

[root@xxyyzz ~]# python3
>>> import grp
>>> grp.getgrnam('starwars')
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1011, gr_mem=['abhi'])
>>> grp.getgrgid(1011)
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1011, gr_mem=['abhi'])

But, when grp.getgrall() is run, we the correct response (gr_mem includes root user as well)

>>> grp.getgrall()
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1011, gr_mem=['root', 'abhi'])]

Actual results:

gr_mem=['abhi'])

Expected results:

gr_mem=['root', 'abhi'])]

Additional info:
Comment 1 Victor Stinner 2020-03-09 08:19:21 UTC 
It seems to work as expected on RHEL8 and Fedora 31:
---
$ sudo groupadd starwars
$ sudo usermod -aG starwars nobody
$ sudo usermod -aG starwars root

$ getent group starwars
starwars:x:1001:nobody,root

$ python3
# Python 3.6.8 on RHEL8, Python 3.7.6 on Fedora 31
>>> import grp
>>> grp.getgrnam('starwars')
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1000, gr_mem=['nobody', 'root'])
>>> [gr for gr in grp.getgrall() if gr.gr_name == 'starwars']
[grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1000, gr_mem=['nobody', 'root'])]
---

Would you mind to provide a full procedure to reproduce your issue? Can you also your group user another tool than python3, like getenv (as shown in my example)?

It seems like root is not part of your starwars group.

On RHEL8, I tested:

# rpm -q python36
python36-3.6.8-2.module+el8.1.0+3334+5cb623d7.x86_64
Comment 2 Abhishek 2020-03-09 09:34:42 UTC 
I am getting the issue in my rhel8 env.. root & nobody are part of starwars group.

$ sudo groupadd starwars
$ sudo usermod -aG starwars nobody
$ sudo usermod -aG starwars root

$ getent group starwars
starwars:x:1011:nobody

$ cat /etc/group | grep star
starwars:x:1011:nobody,root

[root@biplabrhel8 ~]# python3
Python 3.6.8 (default, Oct 11 2019, 15:04:54)
[GCC 8.3.1 20190507 (Red Hat 8.3.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp
>>> grp.getgrnam('starwars')
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1011, gr_mem=['nobody'])
>>> grp.getgrall()
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1011, gr_mem=['nobody', 'root'])]

$ rpm -q python36
python36-3.6.8-2.module+el8.1.0+3334+5cb623d7.x86_64

So, 'getent group starwars' is also not showing root user.

I am wondering if there is any setting newly introduced on rhel8 that hides the root user from being shown in the output.
Comment 3 Victor Stinner 2020-03-09 14:36:05 UTC 
Sorry, I'm not a sysadmin, I don't know how users and groups are usually setup and why you get such behavior.

Would you mind to attach your /etc/nsswitch.conf file to the issue?

Example on RHEL 8 (without comments):
---
# sed '/^#/D; /^$/D' /etc/nsswitch.conf
passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files
shadow:     files sss
hosts:      files dns myhostname
aliases:    files
ethers:     files
gshadow:    files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files
---

Note: On my Fedora 31, I get the same configuration for groups:
---
$ grep ^group /etc/nsswitch.conf
group:       sss files systemd
---

Just in case, you might have a look at the sssd service:
    systemctl status sssd.service
and:
    journalctl -u sssd.service --reverse
Comment 4 Abhishek 2020-03-10 03:19:52 UTC 
/etc/nsswitch.conf file output ignoring comments,

passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files

shadow:     files sss

hosts:      files dns myhostname

bootparams: files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files


publickey:  files

aliases:    files

Here also the config for groups is the same.
---

# systemctl status sssd.service
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-03-04 00:43:25 EST; 5 days ago
 Main PID: 1569 (sssd)
    Tasks: 3 (limit: 26213)
   Memory: 81.9M
   CGroup: /system.slice/sssd.service
           ├─1569 /usr/sbin/sssd -i --logger=files
           ├─1615 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
           └─1627 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files

---

# journalctl -u sssd.service --reverse
-- Logs begin at Mon 2020-03-09 07:35:27 EDT, end at Mon 2020-03-09 23:19:11 EDT. --
-- No entries --
Comment 5 Victor Stinner 2020-03-10 14:19:56 UTC 
Can you please provide the following package versions? Run "rpm -q kernel glibc glibc-common python36 sssd-common".


I failed to reproduce the issue on:

# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.2 Beta (Ootpa)

# rpm -q kernel glibc glibc-common python36 sssd-common
kernel-4.18.0-185.el8.x86_64
glibc-2.28-101.el8.x86_64
glibc-common-2.28-101.el8.x86_64
python36-3.6.8-2.module+el8.1.0+3334+5cb623d7.x86_64
sssd-common-2.2.3-18.el8.x86_64

sssd-common provides /usr/bin.sssd. glibc-common provides /usr/bin/getenv.


Create the starwars group with nobody and root users:

# sudo groupadd starwars
# sudo usermod -aG starwars nobody
# sudo usermod -aG starwars root


/etc/group and getent group agree:

# grep ^starwars: /etc/group
starwars:x:1000:nobody,root

# getent group starwars
starwars:x:1000:nobody,root


Python 3 agree as well:

# python3
Python 3.6.8 (default, Dec  5 2019, 15:45:45) 
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp
>>> grp.getgrnam('starwars')
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1000, gr_mem=['nobody', 'root'])
>>> [gr for gr in grp.getgrall() if gr.gr_name == 'starwars']
[grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1000, gr_mem=['nobody', 'root'])]


User/group database configuration:

# sed '/^#/D; /^$/D' /etc/nsswitch.conf
passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files
shadow:     files sss
hosts:      files dns myhostname
aliases:    files
ethers:     files
gshadow:    files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files
Comment 7 Victor Stinner 2020-03-10 15:08:17 UTC 
I change the component to sssd since "getent group" also has the issue: it's not specific to Python.
Comment 8 Carlos O'Donell 2020-03-10 15:15:14 UTC 
It may be sssd's filter_users, filter_groups (in the [nss] section) which can be used to filter out 'root' from NSS requests.

While I'm just a glibc developer... I'd ask that you provide the /etc/sssd/sssd.conf so we can see if you are filtering users.
Comment 9 Pavel Březina 2020-03-10 16:09:46 UTC 
Does it work if you switch the order of 'sss files' to 'files sss' in /etc/nsswitch.conf?

In general, SSSD, even though it handles local users and groups now, does not handle root user and group (it is automatically added to filter_users and filter_groups). From a quick test, it is indeed causing troubles and this should be marked as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1794607.
Comment 10 Abhishek 2020-03-10 16:35:12 UTC 
# rpm -q kernel glibc glibc-common python36 sssd-common
kernel-4.18.0-147.el8.x86_64
glibc-2.28-42.el8.x86_64
glibc-common-2.28-42.el8.x86_64
python36-3.6.8-2.module+el8.1.0+3334+5cb623d7.x86_64
sssd-common-2.2.0-19.el8.x86_64

There is no /etc/sssd/sssd.conf file on this rhel8 system.

[root@xxxxrhel8 ~]# cd /etc/sssd/conf.d/
[root@xxxxrhel8 conf.d]# ls
[root@xxxxrhel8 conf.d]# cd ../pki/
[root@xxxxrhel8 pki]# ls
[root@xxxxrhel8 pki]# cd
[root@xxxxrhel8 ~]#
[root@xxxxrhel8 ~]# cd /etc/sssd/
conf.d/ pki/
[root@xxxxrhel8 ~]# cd /etc/sssd/conf.d/
[root@xxxxrhel8 conf.d]# ls
[root@xxxxrhel8 conf.d]# cd ../pki/
[root@xxxxrhel8 pki]#
Comment 11 Abhishek 2020-03-10 16:36:22 UTC 
Changing order of 'sss files' to 'files sss' in /etc/nsswitch.conf did the trick. Now it works.

# python3
Python 3.6.8 (default, Oct 11 2019, 15:04:54)
[GCC 8.3.1 20190507 (Red Hat 8.3.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp
>>> grp.getgrnam('starwars')
grp.struct_group(gr_name='starwars', gr_passwd='x', gr_gid=1011, gr_mem=['nobody', 'root'])


# getent group starwars
starwars:x:1011:nobody,root
Comment 12 Pavel Březina 2020-03-12 10:52:19 UTC 
Thank you for confirmation. I will close this as duplication of 1794607.

*** This bug has been marked as a duplicate of bug 1794607 ***
Note You need to log in before you can comment on or make changes to this bug.