change to acl_read module for supporting dirsync module

[Matthieu Patou]

On 09/03/2011 23:07, 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.
Definitely marking the request trusted is not what we want to do as we 
have to be sometimes as a simple user.

> 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.
Nadya, I just remember why I didn't use the mark inaccessible because, 
you are not manipulating the replMetaDataAttribute (or not necessarily 
this one). Of course I could do a search for this attribute and then 
mark it but I'm not sure it would be efficient. What I will do is to 
break the for loop after the first requested attribute that has a denied 
access.

> 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.
I pretty much agree on it.
>   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 :)



-- 
Matthieu Patou
Samba Team        http://samba.org
Private repo      http://git.samba.org/?p=mat/samba.git;a=summary