On Mon, Jan 9, 2017 at 11:51 AM, Jakub Hrozek
<jhrozek(a)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)