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 956235 - newgrp fails with certain nss_ldap/sssd configurations
Summary: newgrp fails with certain nss_ldap/sssd configurations
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: shadow-utils
Version: 6.4
Hardware: x86_64
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-24 13:57 UTC by John Hodrien
Modified: 2019-12-16 04:25 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1425078 (view as bug list)
Environment:
Last Closed: 2015-09-22 11:21:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description John Hodrien 2013-04-24 13:57:48 UTC 
Description of problem:

newgrp fails to function if group member information is suppressed

Version-Release number of selected component (if applicable):
shadow-utils-4.1.4.2-13.el6.x86_64

How reproducible:

Either by configuring sssd or nss_ldap to not populate this information, then trying to use newgrp.

Steps to Reproduce:
1.  Configure the NSS provider to not populate group members.  This means either:
      Configure nss_ldap with nss_getgrent_skipmembers=true in ldap.conf.
  or  Configure a version of sssd that supports ignore_group_members=true

2.  newgrp <a secondary group>

Actual results:
$ newgrp somegroup
Password: 
Invalid password.

Active group is not changed.  newgrp assumes the user is not a member of the group.

Expected results:
$ newgrp 
$ id -gn
somegroup

Additional info:

Populating this information has a massive performance impact on large LDAP installations.  Most (nearly all?) other software discovers group membership by finding out what groups a user is in and then seeing if the required group is present (e.g. using initgroups).  newgrp (and perhaps other commands with shadow-utils) appears to be working the other way round, which fails with these configurations.  Being able to have nss_ldap/sssd configured in this way, and still be able to use commands like newgrp would seem rather desirable.
Comment 2 Tomas Mraz 2013-04-25 09:07:38 UTC 
This is quite risky change which should be discussed with upstream first. Basically we should look at the current supplementary groups and if the new group is in the list, we should allow switching to it without asking for password.
Comment 3 John Hodrien 2013-04-25 09:30:07 UTC 
Yes, I can see that.  Is it worth me trying to get engagement upstream, and commenting back here with anything relevent, or is this just best closed until there's something in upstream worth reopening this for?

The LDAP performance advantage is just so huge of using this setup it seems a shame that we're potentially unable to use it because of such an *outwardly* minor issue (accepting that it's not quite so minor in reality).
Comment 4 Tomas Mraz 2013-04-25 11:02:23 UTC 
If you reported the issue upstream as well it would be nice. You can keep this bug open meanwhile. 

Also using the regular support channels http://www.redhat.com/support and mentioning this bug report would help us to properly prioritize the request in our processes.
Comment 5 RHEL Program Management 2013-10-13 23:40:33 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Note You need to log in before you can comment on or make changes to this bug.