>> To clarify - there is no search operation at all here. > 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 > performance)?
No. Just because it's silly to perform a search when you already have the result available. The purpose of the "filter" ACL clause is to check whether an *already available* entry matches a filter, not to search for it. Performing an internal search would result in something possibly different, and definitely not in what this ACL clause is meant to. >> 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 > about performance?). >> 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: > http://www.openldap.org/lists/openldap-technical/200907/msg00144.html > > > Background-Information: > > 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 > "(&(vNB...)(vNA...))". > > 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, > exceptions, etc. > 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 > on... > > What kind of alternative solutions exist or do you see? I'd rather define a new ordering matching rule for time-valued attrs that checks how a given value compares with "now"; something like "greaterThanNow" and "lessThanNow". This would allow to do something like access to attrs=validnow val/greaterThanNow=19700101000000Z or access to filter=(validnow:greaterThanNow:=19700101000000Z) where 19700101000000Z (the epoch) is used as a placeholder for the asserted value, which would be ignored. Or, I'd write a dynacl module that does the same. I actually wrote one some time ago, and never found it useful. It's here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c> p.
