change to acl_read module for supporting dirsync module

[Matthias Dieter Wallnöfer]

Nadya + Ekacnet,

certainly I let it up to you both to find the best solution (I'm not 
really competent here) but an internal flag sounds very good.

I simply would like to try to remove the number of controls (see my 
RELAX discussion with abartlet & co.) which are often exposed on the 
outside and therefore also error-prone.

Cheers,
Matthias

Nadezhda Ivanova wrote:
> Hi Matthias,
> Matthieu explained to me the logic of the dirsync implementation, so:
> We cannot put dirsync module below acl_read, as dirsync alters the 
> search results based on whether they have been changed since the last 
> replication, and therefore attributes necessary for the access check 
> could be missing from the result.
> We cannot make acl_read check for the original control instead of an 
> internal one, because dirsync module removes that control. I think it 
> would be messy to remove it in the acl_read instead. We cannot make 
> acl_read skip all checks if dirsync control is present, as there is a 
> flag in the dirsync control which requires the regular access checks 
> to be made.
> I suppose if the acl_read module got the SD, sid and objectclass with 
> a separate request that would not be an issue, but I specifically 
> restructured it some time ago to just add them to the original request 
> and pass it down for performance's sake.
> Matthieu, as we discussed, replacing the internal control with a 
> private flag would be great if it's OK with everyone, as checking for 
> controls appears to be slow. Also, as we agreed, instead of removing 
> replmetadata mark it inaccessible, or design a better (faster) way to 
> remove attributes from the message and patch acl_read.
>
> My experience with the acl_read module makes me believe that any 
> module that alters search results should be as high on the stack as 
> possible to avoid messing with the internal workings of other modules. 
> The acl_read could not be on top because it needed the work done by 
> the extended_dn and ranged modules. Because of this a lot of modules 
> above it have to mark their internal requests as trusted (still WIP). 
> Its best not to repeat the story with another module :).
>
> Regards,
> Nadya
>