Re: (ITS#6815) Feature Request: Accesslog filter

[hyc@symas.com]

masarati@aero.polimi.it wrote:
> hyc@symas.com wrote:
>> Andrew Findlay wrote:
>>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc@symas.com 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/