Re: slapd/acl.c: using "filter=()" in an acl does not trigger an overlay's search callback

[Howard Chu <hyc@symas.com>]

Howard Chu wrote:
> Daniel wrote:
> > Hi,
> >
> > my experimental overlay intercepts search requests and modifies the
> > filter-expressions (e.g. removes/expand AND|OR). Therefore the overlay
> > modifies "struct Filter op->ors_filter" on the fly, handles memory
> > (op->o_tmpmemctx/filter_free) and so on. It works fine, currently no
> > memleaks (valgrind) etc and I would like contribute it (once it's
> > finished... ;-) )
> >
> > To get the maximum flexibility out of the current prototyp I'm looking
> > after a solution to have my overlay intercept the following "search", too:
> >
> > access to filter=(description=editMe)
> >       by self write
> >       by * none
> >
> > The ACL's filter seems not to "fire" a search request because in acl.c
> > lines 704 to 709 "test_filter(NULL, e, a->acl_filter)" get's called
> > directly. This results in bypassing the overlay's search callback. Was
> > this for performance reasons?
> >
> > Are there any chances to replace "test_filter()" by some kind of
> > slapd_internal_search() in a way to enable overlay stack processing, for
> > this internal search?
>
> No.

To clarify - there is no search operation at all here. It is simply comparing 
the ACL terms to the target entry for which access is being checked. The 
target entry may be the target of a Modify, Compare, etc., not necessarily a 
Search request. And there is no reason to perform an internal search, since 
the target entry is already in hand, being evaluated.

Whatever your overlay is doing, it seems silly to invoke it here. If you want 
a different filter, just write the desired filter into the ACL. Rewriting a 
static configuration item every time it's evaluated is rather wasteful.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/