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

[masarati@aero.polimi.it]

> Daniel schrieb:
>> masarati@aero.polimi.it schrieb:
>>>> 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.
> After some experiments with MRs I think that I have not understood your
> suggestion the right way or your suggestion is misleading...
>
> In case the two new MRs "earlierThanNow" and "laterThanNow" are new
> ORDERING MRs they have to be compared using lt- or gt-operators, haven't
> they?

No, you need to use an extensible filter, which is sort of a generalized
assertion.  What you use is "attr:mr:=value".  Then, it's the purpose of
"mr", your custom matching rule, to perform something that is equivalent
to an ordering match.  Your attributes do not need to have anything
special about matching rules.  They could even have no matching rule
defined.  All they need is to have "generalizedTime" syntax, so that your
custom matching rule can be applied.

> This leads me to the question why are there two MRs needed if the
> operator could be used to tell the difference... (e.g. earlierThanNow:
> "<"   and   laterThanNow: ">")?

Because you need two separate assertions for earlierThanNow and laterThanNow.

> Another question concerns the schema-definition of the two dead-end
> attributes "validNotBefore" and "validNotAfter": In my current
> definition both are of type "generalizedTime", EQUALITY is
> "generalizedTimeMatch" but what should I use for ORDERING?

See above.  Nothing is needed about equality.

>  From the results of my MR-tests I think I should/could:
> 1. define ORDERING using "generalizedTimeOrderingMatch" (to make
> standard LE/GE ldapsearch filtering using "<=" and ">=" work out of the
> box)

That makes sense, although it would be orthogonal to using the
earlierThanNow/laterThanNow rules through extensible filters.

> 2. use the two additional MRs on-demand (replacing the above "default"
> ORDERING by the new ones), e.g.:
>      (validNotBefore:earlierThanNow:<epoch) or/and
> (validNotBefore:earlierThanNow:>epoch)

The above string representations do not conform to LDAP search filters. 
See RFC 4515 for a definition of extensible match.

> Would this be possible or ok? What alternatives do you possibly see or
> suggest?

Stick with the original plan, implement it correctly.

p.