change to acl_read module for supporting dirsync module

Nadezhda Ivanova nivanova at
Wed Mar 9 05:08:18 MST 2011

This patch is actually the implementation of an AD LDAP control, so... no
way to avoid using the control itself, I suppose :).

On Wed, Mar 9, 2011 at 11:08 AM, Matthias Dieter Wallnöfer <mdw at>wrote:

> ekacnet,
> I've also looked about this patch - two comments:
>   * Is there a real reason that the module has to be located below the
>     ACL one? I'm raising this thought since if there is none we could
>     save us an additional control and simply put it higher. We really
>     need to start avoiding controls where not strictly necessary.
>     Another way could be to use the new "trusted/untrusted" mechanism
>     for getting "replPropertyMetaData".
>   * I've also performed a quick review of the control implementation
>     and I've noticed some type problems:
>         o The counter variables aren't appropriate yet. LDB objects
>           are counted as "unsigned int". That means the following in
>           the downto manner: for (i >= ...num_values - 1; i !=
>           (unsigned) - 1; i--).
>         o On "for (i=0; i < rmd.ctr.ctr1.count; i++) {" "i" should be
>           "uint32_t" since we are working os DSR stuff.
>         o "functional_level" in "struct dirsync_control" should be
>           typed as "int".
>         o "addedAttributes" I would type as "unsigned int" (the same
>           as "num_elements" in LDB).
> Otherwise your work really seems very promising. Also the problem with the
> partition control should be sorted out as soon tridge finishes my patchset
> review.
> Cheers,
> Matthias
> Matthieu Patou wrote:
>> Hello Nadya,
>> Can you have a look at this:
>> And tell me if you are OK, basically it's about not to return LDB_SUCCESS
>> when a searched attribute is not accessible but instead to remove the
>> replPropertyMetaData attribute to give the signal to dirsync that the user
>> didn't have an access on this object and so an empty DN with just the
>> objectGUID should be returned.
>> Matthieu.

More information about the samba-technical mailing list