Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=746181
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
This one is a little tricky. We store the group in the cache using the group's name as its DN. But if we change names and then do a lookup by GID, we don't purge the old group from the cache. So now it looks like we have two groups in the cache with the same ID.
Group name changes are tricky things. It's difficult to know whether a group's name has actually changed or we've looked up a new group with the same ID.
Since we can't really support the latter case anyway, I'm inclined to say that the fix for this would be to check the cache for other entries with the same ID before saving it and delete them if the name does not match.
This affects users as well.
coverity: => description: https://bugzilla.redhat.com/show_bug.cgi?id=746181
{{{ 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:
Checking groups in domain resulted in this: [root@SERVERNAME db]# getent group |grep -i gr GROUPGROUP::10069:username groupgroup::10069:username
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
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 }}} => https://bugzilla.redhat.com/show_bug.cgi?id=746181
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 }}}
patch: => 0 rhbz: => tests: => 0 testsupdated: => 0 upgrade: => 0
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.7.0
Marking ticket #1076 a duplicate of this bug.
SSSD has a hard restriction in the SysDB that only one group can exist with a particular ID.
When a group is renamed on the server, it becomes an order-of-operations issue whether or not we handle it correctly. If we look up the old group name first, we'll see it's removed and delete it from our cache. If we ask for the new group name, we'll get an error attempting to save it to the cache because the IDs will match.
It's well-documented that we don't support multiple entries with the same GID and that doing so will result in unexpected behaviour, so I'd like to recommend the following change:
When we attempt to save a group to the sysdb and the lookup reveals that another group exists already with that GID, instead of failing we should remove the old group. If there actually ARE two groups with the same GID, the effect will be that they'll regularly remove each other, causing a lot more LDAP lookups (and confusing offline access), but this isn't a supported configuration anyway.
In the case that it's actually a rename, we'll handle things much more gracefully.
cc: => patrik.martinsson@smhi.se owner: somebody => jzeleny
Bumping the priority of this ticket to "critical", as we're seeing this issue occur more as people are using SSSD for longer periods in their environments.
priority: major => critical
summary: "getgrgid call returned more than one result" after group name change in MSAD => SSSD does not handle group renames safely
patch: 0 => 1 status: new => assigned
milestone: SSSD 1.7.0 => SSSD 1.6.3
Fixed by: - 583f7e8 (master) - 42fb63b (sssd-1-6)
resolution: => fixed status: assigned => closed
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=746181 746181]
Metadata Update from @sgallagh: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.6.3
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2082
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.