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