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 746181 - "getgrgid call returned more than one result" after group name change in MSAD
Summary: "getgrgid call returned more than one result" after group name change in MSAD
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.1
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 736857 756082
TreeView+ depends on / blocked
 
Reported: 2011-10-14 09:24 UTC by Kemot1000
Modified: 2020-05-02 16:27 UTC (History)
6 users (show)

Fixed In Version: sssd-1.8.0-2.el6.beta2
Doc Type: Bug Fix
Doc Text:
Cause: when we were adding new group to SSSD cache, we weren't checking if another group with the same GID was already in the database Consequence: if another group with the same GID already existed in the cache when we were trying to add a new one, both groups would continue to exist in the cache which would be obviously problematic if the original no longer existed on the server Fix: when adding new group to the cache, delete any group with the same id that is already in the cache Result: only one group with one GID exists in the database. Therefore multiple groups won't be returned to client in case a group was renamed
Clone Of:
Environment:
Last Closed: 2012-06-20 11:48:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 2082 0 None closed SSSD does not handle group renames safely 2020-05-18 21:09:38 UTC
Red Hat Product Errata RHBA-2012:0747 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2012-06-19 19:31:43 UTC

Description Kemot1000 2011-10-14 09:24:45 UTC 
Description of problem:
We changed one of the groups name in MSAD that was defined as Unix group from uppercase to lowercase. After that we noticed problems with some of the services. In sssd_nss.log we got error messages:

(Fri Oct 14 10:03:31 2011) [sssd[nss]] [nss_cmd_getgrgid_search] (0): getgrgid call returned more than one result !?!

Problems:

1. Checking groups in domain resulted in this:
[root@SERVERNAME db]#  getent group |grep -i gr
GROUPGROUP:*:10069:username
groupgroup:*:10069:username

2. Cache was not updated correctly even after we removed group from Domain and added it again. 
[root@SERVERNAME db]#  getent group |grep -i gr
GROUPGROUP:*:10069:username
groupgroup:*:10113:username

We got expected result only after removing cache from /var/lib/sss/db directory. Resetting service didn't help. 
[root@SERVERNAME db]#  getent group |grep -i gr
groupgroup:*:10113:username

3. What is the configuration parameter responsible for cache refresh ? I would like groups / users and memberships to be updated asap. 


Why if MSAD is case insensitive it is important for SSSD what case group/user has ?? 



Version-Release number of selected component (if applicable):
sssd-client-1.5.1-34.el6_1.3.x86_64
sssd-1.5.1-34.el6_1.3.x86_64
Comment 2 Stephen Gallagher 2011-10-14 11:16:50 UTC 
The reason that SSSD behaves in a case-sensitive manner because this is mandated by the POSIX specification. All glibc interfaces for users and groups are case-sensitive, and therefore we must be also.

We have an open ticket to behave better in environments like AD which are case-insensitive: https://fedorahosted.org/sssd/ticket/890

The idea here will be to force all identifiers to lower-case on the client machine, regardless of their case on the server.

You *have* identified a rather odd bug in the getgrgid() code though. If you were looking up a group directly by GID, it should have completely replaced the old entry in the cache.
Comment 3 Stephen Gallagher 2011-10-14 11:23:54 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1040
Comment 4 Kemot1000 2011-10-14 11:54:19 UTC 
(In reply to comment #2)

What do you mean? 
 
> If you were looking up a group directly by GID, it should have completely
> replaced the old entry in the cache.

Is there any way to force cache entry to be replaced during next lookup involving user / group that changed in domain?
Comment 5 Stephen Gallagher 2011-10-14 12:01:40 UTC 
Sorry, I phrased that poorly. There's a bug in our code in that it only checks whether the current name already exists in our cache. It doesn't check for entries with the same ID. I've opened ticket 1040 upstream to fix this.
Comment 8 Jan Zeleny 2012-04-04 11:37:45 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: when we were adding new group to SSSD cache, we weren't checking if another group with the same GID was already in the database
Consequence: if another group with the same GID already existed in the cache when we were trying to add a new one, both groups would continue to exist in the cache which would be obviously problematic if the original no longer existed on the server
Fix: when adding new group to the cache, delete any group with the same id that is already in the cache
Result: only one group with one GID exists in the database. Therefore multiple groups won't be returned to client in case a group was renamed
Comment 9 Kaushik Banerjee 2012-05-03 07:08:26 UTC 
Verified in sssd-1.8.0-25


Steps to verify:

1. Add a group USER11_GRP1

2. Configure sssd with enumerate=true and check the enumerated result.
# getent group | grep -i user11_grp1
USER11_GRP1:*:11039:user11

3. Rename the group to lowercase i.e. user11_grp1

4. After the next enumeration refresh, check the result again
# getent group | grep -i user11_grp1
user11_grp1:*:11039:user11
Comment 10 Kaushik Banerjee 2012-05-14 11:34:36 UTC 
Retested with sssd-1.8.0-27.

With uppercase groupname:
# getent group | grep -i user11_grp1
USER11_GRP1:*:11039:user11

After renaming to lowercased name:
# getent group | grep -i user11_grp1
user11_grp1:*:11039:user11
Comment 12 errata-xmlrpc 2012-06-20 11:48:38 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2012-0747.html
Note You need to log in before you can comment on or make changes to this bug.