Howard Chu wrote:
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
>> lines 704 to 709 "test_filter(NULL, e, a->acl_filter)" get's
>> 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?
Thanks a lot for your second reply. I think I need to explain this
stupid thing in more detail:
To clarify - there is no search operation at all here.
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
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
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?