[Date Prev][Date Next]
Re: Limiting filter types based on op_ndn
At 10:24 AM 2001-09-22, Pierangelo Masarati wrote:
>I've been working for a couple of days on limiting filter types
>in search operations based on op_ndn. I'll commit the change
>as soon as I test it (I'm particularly busy at the moment :)
>It works as follows: a set of limits can be enforced based on
>the dn that requires the search. These limits cause the server
>to respond "unwilling to perform" if the limitation is hit.
>The filter type can be limited for an attribute or a regular
>expression; the dn that is subject to the limitation can be expressed
>as a regular expression as well.
>pres, eq, sub, approx and ordering filters can be limited separately.
>We felt this need to protect a DSA against DOS-like attacks
>(people browsing directories for hours requesting everything each time
>possibly due to dumb clients).
I might be a bit confused as to actually what you are suggesting,
(maybe an example would be useful), but...
I think this is best done by restricting the number of candidates
to be checked as a user can easily assert a filter which requires
testing of all entries within scope. Apply restrictions to the
types of filters a particular client can assert (as opposed to
evaluating those filters to Undefined) will likely be ineffective.
Do you really think folks will disallow (objectClass=*) or
other always true filters?
>The limits are tested before the operation is initiated, so there's
>no overhead. This can be used in conjunction with the already
>implemented limit on the candidates a search selects and the soft/hard
>size/time limits to protect the amount of data (and the resources)
>a DSA is willing to return based on the identity that issues the request.