change to acl_read module for supporting dirsync module

Nadezhda Ivanova nivanova at
Fri Mar 11 01:04:24 MST 2011

Hi Kamen,
The way I understood it, the acl_read needs to do a bit of extra filtering
if the dirsync control with a certain flag is present in the request. It is
just an extra action depending on the result of access checks and whether we
have dirsync control specified, not a dependency. To avoid this, we will
have to repeat a lot of the code from acl_read in dirsync module, or have
acl_read signal dirsync that attributes are inaccessible to this user, which
I think is more of a dependency that just checking for the same control.


On Fri, Mar 11, 2011 at 12:55 AM, Kamen Mazdrashki <kamenim at>wrote:

> 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.
> --
> CU,
> Kamen
> 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