On Tue, Jan 10, 2017 at 10:12:37PM +0100, Fabiano Fidêncio wrote: > On Mon, Jan 9, 2017 at 11:51 AM, Jakub Hrozek <jhro...@redhat.com> wrote: > > On Sun, Jan 08, 2017 at 09:58:22PM +0100, Fabiano Fidêncio wrote: > >> I've been working on rhbz#1401241 > >> (https://bugzilla.redhat.com/show_bug.cgi?id=1401241) and I'd like to > >> clarify some doubts that showed up. > >> > >> So, let's consider that there's a group called "foo" and user "user" > >> is part of this group. Group "foo" gets renamed to "bar'. Now. let me > >> describe what I've found out considering "id_provider = ldap" and > >> "id_provider = ad" > >> > >> - id_provider = ldap: > >> cache has "foo" entry > >> After renaming "foo" to "bar" > >> cache has entry "bar" added > >> both entries have the same gid > >> > >> - id_provider = ad > >> cache has "foo" entry > >> After renaming "foo" to "bar" > >> nothing is changed in the cache > >> > >> Any of these situation look exactly right for me (and here I'm > >> probably wrong). My expectations are that we should, for both cases: > >> - check for the gid in the cache > >> - update the entry > > > > Unfortunately renaming users and groups is not so easy because of the > > member and memberof links. The memberof link points from the user to the > > group and contains the name of the entry they point to, therefore need to > > be changed one way or another during the group rename. > > > > If the group was renamed using ldb_rename(), then the link change should > > be done by the memberof ldb plugin, but it's not implemented there. > > > > Since the memberof plugin only implements add, del and modify > > operations, we solve this by removing the group and re-adding it with > > different name in sysdb_store_new_group(). > > > >> > >> So in the ldap case we would avoid having two entries with the same > >> gid and in the ad case we would be able to properly the updated name > >> of the group that the user is part of. Does it make sense? > > > > I wonder why we have two entries with a duplicate gid in the first > > place. When saving the duplicate "bar", don't we hit > > sysdb_store_new_group() -> sysdb_delete_group() ? > > According to my tests this part is never triggered. May be because > it's using rfc2307bis? > > What I can see here is that I ended up in: > - sdap_add_incomplete_groups(), which tries to search the group by its > name and, obviously doesn't find it, so the missing group ends up > being saved (again). > > I've tried to search by the group id instead of searching by the group > name, which works fine for this part, but then breaks when saving the > user memberships (in case searching a user that is not cached), as the > group with the new name is not found. > > So, yeah, I guess what we are missing here is just deleting the old > group and add the new one in this case, but I still have to figure out > how to do that (and if I get stuck on it, don't worry, I'll bother > some of the developers on IRC). > > One thing that I'd like to be sure is that it does make sense to be > done when using rfc3207bis.
(I haven't tested this at all, just replying based on my code knowledge) I wouldn't expect the schema to matter, this is handled at the sysdb level. So I think it's a bug -- if you have an environment that reproduces it and would like me to take a look, feel free to ping me on IRC (tomorrow, please :-P) _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
