[email protected] wrote: > [email protected] wrote: >> Andrew Findlay wrote: >>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, [email protected] wrote: >>> >>>> Possibly we can extend the directive to handle exclusion as well as >>>> inclusion, >>>> to simplify this case. >>> Extending this idea slightly, would it be possible to have >>> exclusions based on changes to specific attributes? The >>> particular case I have in mind is where accesslog is used to >>> keep a permanent audit log of changes, and ppolicy is also >>> in use, resulting in one audit entry for every login >>> failure. I have one site where a large proportion of the auditlog >>> entries are login failures... >> >> Perhaps in that case, it would be simpler just to set ppolicy's mods to be >> internal-only and bypass the accesslog overlay. (Currently it does this >> already, if the server is a single-master replica.) >> >> So far you're talking about two different enhancements - the original poster >> is trying to exclude a set of searches, and you're talking about excluding >> modify ops. I'm not seeing any way yet to generalize from here such that all >> operation types are addressed meaningfully, and I don't want to introduce >> multiple special cases to the config language. > > A URI-based restriction specification could include/exclude based on > suffix, filter and listed attributes with a unified syntax.
Yes... But what does the filter *mean* in a modify op? filter on the target entry before it was modified, or after? a search op? match the search request's filter, or filter on the search base? a compare op? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
