(ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group

[gerry@everythingsucks.co.uk]

Full_Name: Gerry Calderhead
Version: OpenLDAP 2.4.25
OS: Linux RHEL5.5
URL: http://uploading.com/files/529d29ce/0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch/
Submission from: (NULL) (80.238.1.135)


What we're trying to do
-----------------------
We are using OpenLDAP + GOsa to manage users who have access to an extranet.
There are a set of tools on the extranet, let's call then VCS, Bugs, Wiki.
The extranet is accessibly by third-parties.

We want to delegate some admin to staff in the third parties.
The structure we want to use is:

Multiple organisations
Each organisation has a group per tool, e.g. VCS_access, Bugs_Access,
Wiki_Access.
Organisation admins can add people to their own groups.

We then want to aggregate all people with access to those tools into some top
level groups, e.g.
 
   all_VCS_access = org1.VCS_access + org2.VCS_access
   all_Bugs_access = org1.Bugs_access + org2.Bugs_access
   all_Wiki_access = org1.Wiki_access + org2.Wiki_access

It's important to us that when people are added/removed to the organisational
groups that the group
'member' attributes and the user's 'memberof' attributes are correct and
consistent as these
for the basis for our access management.

Observed Problem
-----------------
If you add a user to a monitored group they are consistently added to the target
group.  You can now search for them using a memberof filter.

If you then remove the user from a monitored group they are consistently removed
from the target group.  However if you then search for members of the target
group using a memberOf filter the removed users always show up.  100%
reproducible in our environment.

Analysis
--------
When using bother AutoGroup + MemberOf the "memberof" attributes
are not always deleted when users are removed from a group.

The approach this overlay takes to updating the target members list,
when a member of a monitored list is removed, is to basically
clear the membership and re-populate based on a search.

Generally the Autogroup Entry requiring a refresh will be flagged in
autogroup_modify_entry function.

Within this response function we will then spot these flagged refreshes
and will perform the deletes and searches to re-polulate the groups.

So far, so simple.

However, this response function is not necessarily executing in response
context
of the original modification (say of a "member") but could be in response
to a different modification, specifically the addition of a "memberOf"
attribute.
i.e. it behaves asynchronously - refreshing the group sometime after the
initial change.

This is a problem when you wish to use MemberOf and AutoGroup together.
 		1. Admin removes a "member" of a group
 		2. AutoGroup spots the removal from a trigger group and flags a refresh on
the
 		   AutoGroup Entry for the target group.
 		3. MemberOf overlay's _modify function is called, spots the removal of the
"member"
 		   and updates the "memberOf" attribute of the trigger group.
 		4. This response function is called in the context of "memberOf" update
 		5. We spot the flag on the AGE, and delete all "member"s from the target
 		   and initiate searches to re-populate.
		6. The MemberOf overlay's _modify function is called in response to the
"member"
		   changes in the target group (5).
		8. MemberOf's _modify function is guarded against recursion, and exits
immediately
		   without removing the "memberof" attributes from the users in the target
group.
		9. When the search completes all remaining "member"'s will be re-added to the
target
		   group.  The users will have their "memberOf"'s updated but the chance to
remove
		   the dead "memberOf"'s is gone.  These will now linger around in the DB.

So, the simplest solution I can think of is that we do not make any changes in
the context of
a modification that may have originated from the MemberOf overlay and instead
wait on
the next opportunity to trigger the refreshes.

In reality if the trigger for the refresh was a "member" change then the refresh
will happen
during the course of the corresponding _response's - just not on any which
modify "memberof".

Fix
----
Add the following lines at the start of autogroup_response()

if ( op->o_tag == LDAP_REQ_MODIFY ) {
		Modifications	*mz;
		for ( mz = op->orm_modlist; mz; mz = mz->sml_next ) {

			if ( mz->sml_mod.sm_desc == agi->agi_memberof_ad )	{
				Debug(LDAP_DEBUG_TRACE,"==> autogroup_response in context of 'memberof'
modification, do nothing!\n", 0, 0, 0);
				return SLAP_CB_CONTINUE;
			}
		}
	}

Full git-format-patch present at URL specified.

sha1sum 0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch 
76c2cf268fff37c0cd744e7b3cfd0afa63d9e991 
0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch


Public Domain Notice
--------------------

I, Gerry Calderhead, hereby place the following modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.