SSSD does not handle group renames safely #2118

sssd-bot · 2020-05-02T12:26:09Z

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1076

Created at 2011-11-02 14:36:16 by sgallagh
Closed as Duplicate
Assigned to nobody

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.