Re: slapd/acl.c: using "filter=()" in an acl does not trigger an overlay's search callback

[masarati@aero.polimi.it]

>> 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.