[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

Howard Chu wrote:
Daniel wrote:

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?


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/