[Date Prev][Date Next]
Re: slapd/acl.c: using "filter=()" in an acl does not trigger an overlay's search callback
Howard Chu 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/