+++ This bug was initially created as a clone of Bug #956235 +++
Description of problem:
Pretty much copy/paste from original bug but more focused on sssd since that is what I've tested.
newgrp fails to function if group member information is suppressed
Version-Release number of selected component (if applicable):
shadow-utils-4.1.5.1-24.el7.x86_64
How reproducible:
By configuring sssd to not populate this information, then trying to use newgrp.
Steps to Reproduce:
1. Configure SSSD to not populate group members by setting 'ignore_group_members' to 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.
--- Additional comment from Tomas Mraz on 2013-04-25 05:07:38 EDT ---
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.
--- Additional comment from John Hodrien on 2013-04-25 05:30:07 EDT ---
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).
--- Additional comment from Tomas Mraz on 2013-04-25 07:02:23 EDT ---
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.
--- Additional comment from RHEL Product and Program Management on 2013-10-13 19:40:33 EDT ---
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.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:3063