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.