Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1301655

Summary: Getent ignores netgroups in /etc/passwd with passwd_compat sss
Product: Red Hat Enterprise Linux 7 Reporter: Andreas N. <fo_ko>
Component: glibcAssignee: DJ Delorie <dj>
Status: CLOSED INSUFFICIENT_DATA QA Contact: qe-baseos-tools-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: ashankar, codonell, fo_ko, fweimer, grajaiya, jhrozek, jon.lickey, lslebodn, mkosek, mnewsome, mzidek, pbrezina, pfrankli, vmukhame
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-02 17:27:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andreas N. 2016-01-25 15:39:37 UTC
Description of problem:

If someone in nsswitch.conf uses the compat mode for passwd with sssd

passwd:         compat
passwd_compat:  sss

and in /etc/passwd the netgroup entry (e.g +@netgroup). With "getent passwd" the users in this ldap netgroup don't get listed. "getent passwd [username]" works perfectly fine. Also, if instead of netgroup "group", we write just a netgroup user (e.g. +username) it works as it should. The only problem is with groups.


How reproducible:
always


Steps to Reproduce:

1. Set in nsswitch.conf

passwd:         compat
passwd_compat:  sss

2. Set a netgroup group in /etc/passwd

+@netgroup

3. Do a "getent passwd"


Actual results:

only the local users of passwd get listed. ldap users in the netgroup don't get enumerated.


Expected results:

ldap users in the netgroup should be listed too.


Additional info:

This seems to be a really old bug. Take a look here https://www.redhat.com/archives/rhelv5-list/2011-September/msg00003.html
I tried to set the NIS domain but for me didn't work.

Comment 2 Jakub Hrozek 2016-01-25 22:10:48 UTC
I admit I haven't really used the compat mode myself, but:
 1) Can you enumerate the users in the netgroup?
 2) did you enable enumerate=true in sssd.conf?
 3) can you request individual users?

Comment 3 Andreas N. 2016-01-26 09:25:38 UTC
(In reply to Jakub Hrozek from comment #2)
> I admit I haven't really used the compat mode myself, but:
>  1) Can you enumerate the users in the netgroup?
>  2) did you enable enumerate=true in sssd.conf?
>  3) can you request individual users?

Hello Jakub,

1) If I give "getent netgroup [netgroup name]" it works as it should. It lists me the netgroup elements.

2) If you enable the enumerate in sssd.conf then you get a list with all the ldap users. That is why I wanted to do the enumeration with compat and passwd, in order to avoid the listing of all users in the ldap directory and just decide which netgroup users I want to get listed.Before the sssd times it used to be done like this.

3) Individual users can be requested. Like I said, if you write in passwd +username and do a "getent passwd" it works without problem. The problem is only with groups.

Comment 4 Jakub Hrozek 2016-01-27 15:00:35 UTC
If the lookups work, then I think it's out of the hands of sssd and into the realm of libc..

Comment 5 Florian Weimer 2016-11-24 17:09:20 UTC
On the glibc side, we need more verbose instructions how to configure a system so that it reproduces this issue.  Thanks.

Comment 7 DJ Delorie 2017-08-30 21:01:55 UTC
In my testing, I've found that I can reproduce this problem if I populate the netgroups like this:

nisNetgroupTriple: (testuser23000.example.com,,)

but if I instead populate the netgroups like this, it works correctly:

nisNetgroupTriple: (,testuser23456,)

Could you please check your ldap database and see how the nisNetgroupTriples are formatted?

Comment 9 Florian Weimer 2020-04-16 13:12:12 UTC
We have not received the requested information in comment 7.

Comment 10 Jon Lickey 2020-07-17 16:07:19 UTC
We are having the same issue, and our netgroup users are setup as suggested.

nisNetgroupTriple: (,testuser23456,)

What I have discovered is that if we modify the entry in /etc/nsswitch.conf from:

passwd:         compat
passwd_compat:  sss

to:

passwd:  files sss

all accounts listed setup in ldap show up when running "getent passwd". But I would like to limit this based on netgroups instead, so I put the compat portion back and verified that we do have +@netgroup at the bottom of /etc/passwd.

Comment 11 Carlos O'Donell 2020-09-02 17:27:07 UTC
The Platform Tools glibc team is unable to reproduce this issue given the current information.

We suggest that you work with Red Hat Support to arrive at a reproducer that the glibc team can use to help resolve the issue or suggest a workaround.

Comment 12 Red Hat Bugzilla 2023-09-14 03:16:44 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days