[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



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