[Freeipa-devel] [PATCH] 734 Add handling for indirect memberof other entries.

[Rob Crittenden]

Dmitri Pal wrote:
> On 02/21/2011 08:52 AM, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Mon, 21 Feb 2011 11:56:39 +0100
>>> Jakub Hrozek<jhrozek at redhat.com>   wrote:
>>>
>>>> On Sat, Feb 19, 2011 at 11:47:45PM -0500, Rob Crittenden wrote:
>>>>> I had to add a couple of short sleep calls to make things work a
>>>>> little better. The memberof plugin runs as a postop and we have no
>>>>> way of knowing when it has done its work. If we don't pause we may
>>>>> show some stale data that memberof hasn't updated yet. .3 seconds is
>>>>> an arbitrary choice.
>>>>>
>>>>
>>>> I don't know the DS plugin architecture good enough but there's no
>>>> callback or anything we can hook to? If the machine swaps or
>>>> something, we might get incorrect data with the sleep anyway..
>>>
>>> Unfortunately the way plugins are done, post-ops are pretty much
>>> impossible to catch from the outside.
>>>
>>> And I really don't like this either.
>>> I would definitely prefer for the reply to the modifying client to wait
>>> until the memberof plugin is done, even if this means the operations
>>> will be slow.
>>> But I don't know if this can be done easily with the current DS
>>> architecture ...
>>>
>>> The problem is that we cannot even enter a read loop to wait smaller
>>> amounts of time until we get back the right answer because a competing
>>> client may change the membership while we are waiting and causing us to
>>> loop forever ...
>>>
>>> Simo.
>>>
>>
>> This is the same conclusion I came too and decided that a brief sleep
>> is the lesser of evils.
>>
>
> Can this be fixed by the memberOf plugin?
> If the memberOf plugin is modified to also change/set the attribute
> there should not be a race condition.
> What is the recommendation from Rich and Nathan?
> I am fine with the temp fix but should we have a ticket to fix it in a
> better way in 2.1?

This is a race condition only in that we're racing against the memberOf 
plugin.

Take the case of a group the a member user:

If you remove the member attribute from the group then immediately do an 
ldap search for ("member=cn=group,...") you may very well get the user 
if the memberOf operation isn't completed yet.

In this case it makes the user look like an indirect member of the group 
(because they are no long in the group's member attribute).

I talked to Nathan about this on Friday. memberOf runs as a postop so 
only runs once the modification results have been sent. So from the IPA 
perspective the work is complete and we move along. We don't get any 
sort of ID that we can query on to see if memberOf is done, and at the 
point of our operation we have no idea what scope of work memberOf has 
to do, it could be extensive (think about a group of 1000 users and you 
delete the group, it has to remove memberOf from all those 1000 users).

rob