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

[Daniel <deepee@gmx.net>]

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.

The attr "validnow" does not really exist. It's used for "detection" 
purposes only (that's the kind of protocol violation I've talked about).

The effective (exploded) filter contains the entries validity period's 
dead-ends (both generalizedTime Syntax):
"validNotBefore" and "validNotAfter" which might be exist in an entry.

Nevertheless, I think I've understood your suggestion. I'll investigate 
into the direction of two additional MRs and try to implement them:

earlierThanNow and laterThanNow

This would result in a filter statement like this:
(&(validNotBefore:earlierThanNow:=epoch)(validNotAfter:laterThanNow:=epoch))

Sounds this correct?

Thanks a lot!

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

I have already had a look into contrib/slapd-modules/acl and decided: 
dynacl in general is not what I think I'll need or want. The 
ACL-processing would have been only a "nice to have". The core 
functionality is the server side transparent enforcment in combination 
with the bypass-exception. I have understood the dynacl contrib code the 
way, that only "by" clauses could be handled...