change to acl_read module for supporting dirsync module

Kamen Mazdrashki kamenim at
Thu Mar 10 15:55:31 MST 2011

Hi Matthieu,

Sorry I am entering this discussion so late, but I just want to share with
you my concerns about this patch.
I haven't looked in depth your 'dyrsinc' patches, so excuse my ignorance
if I am missing something :)
And thanks a lot for taking the Dyrsinc task!
(it was about time for us to support it)

My main concern is that this patch makes a subtle link between acl_read
module and dyr_sync module. I don't feel like it is the responsibility of
acl_read module to "know" we are processing another control or something.
As far as I see it, we should make our best to implement clean interfaces
between module. I mean, that it is very complex to support a filter system
like that in LDB when there are inter-dependencies between modules.

Can we avoid this somehow?
One way to avoid this is for us to mark certain attributes as INTERNAL
or SERVICE or something else (I think we have such a mechanism
introduced by abartlet and tridge with attribute flags).
What I am thinking is, that it will be easier to teach modules like acl_read
not to touch attributes with given flags, rather that teaching them how to
work in different situations.


On Wed, Mar 9, 2011 at 00:34, Matthieu Patou <mat at> 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.
> --
> Matthieu Patou
> Samba Team
> Private repo;a=summary

More information about the samba-technical mailing list