[Date Prev][Date Next]
Re: slapd/acl.c: using "filter=()" in an acl does not trigger an overlay's search callback
Howard Chu wrote:
Thanks a lot for your second reply. I think I need to explain this
stupid thing in more detail:
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
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,
this internal search?
Yes, that's what I've already (not) found out before. And it was the
reason for my initial question. Why is test_filter() called directly
here instead of an internal search (my assumption: probably because fo
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.
Ok, this answers why test_filter() is called directly - thanks. But how
can an overlay possibly intercept this or what has to be change that an
overlay can intercept this? My thought was: maybe by doing a
"internal_search(scope base on entry e with filter a->acl_filter)" (how
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.
These were exactly my doubts too, please see:
I've been searching after some kind of new LDAP feature (currently aka
protocol-violation ;-) ) - mostly comparable to SQL's "select * from *
where timestamp=now()". Translated into LDAP this would perhaps mean
something like: "ldapsearch ... -H ... '(validnow=*)'"
Violating the LDAP-protocol by highjacking a "search-filter-expression"
seems not to be the most elegant ldap-way (in regard to protocol
extensions and the use of new extend controls etc), but:
This functionality should be a server-side-controlled&enforced feature
(customizable for different subtrees etc. pp.). The Server is able to
detect the above "special" PRESENT-filter and replace it on-the-fly
into: '(&(validNotBefore<=op's time)(validNotAfter>=op's time))'.
Additionally the server (overlay) enforces this kind of filtering
transparently below distinct subtrees. This means: an incoming
ldapsearch '(objectclass=*)' gets extended to
(&(objectClass=*)(validnow=*)) and "validnow=*" itself explodes into
EQUALITY-Filters are handle the way that any incoming filter that
contains: "validnow=19700101000000Z" get transformed into
'(&(vNB<=1970...Z)(vNA>=1970...Z))'. Only in case the req_ndn is allowed
to bypass or the resulting objects are allowed to be ignored.
Although this feature could be completly integrated into an
catch-all-overlay I've split it into two parts: a slapd-internal
validnow-core-part (very rare changes to filter.c only three additional
functions, no changes to existing code) to fulfill the above (simple)
feature. And an validnow-ctrl-part to handle subtree-configuration,
The validnow-ctrl uses a fine grained configuration matrix to allow
distinct entries and rdn-subtrees to bypass the server side enforcement
under special circumstances (globally and/or locally configurable).
All this works fine: under enforced subtrees only valid objects are
returned and only valid objects are allowed to authenticate, exceptions
are handled correctly etc. I've successfully tested the behavior
regarding bind-operation (simple & sasl) and various search
request-scenarios. If the server respond (with an enforced/limited
reply) extended control's are added to the reply, to inform
validnow-capable clients (already tested). Currently the compare, add
and modify is work in progress.
Now I want to come back to the original question: It would be nice to
let validnow also take effect on slapd's ACL processing, e.g.
access to filter=(validnow=*)
by users search
by * none
I've already tried to "modify/replace" the a->acl_filter struct
(quick&dirty hardcoded within in acl.c). It has worked fine for the
first request but during the second request slapd segfaults away ;-). I
think the overlay traversal [sh|w]ould work better...
In my opinion the above partially described feature (possibly not this
solution) would be a very interessting LDAP feature especially in regard
to authorization, provisioning and de-provisioning, data privacy and so
What kind of alternative solutions exist or do you see?