[Date Prev][Date Next]
Re: Substring searches
I don't think fine grained controls is not the answer. Consider:
Why should the search fail just because one component of the
filter has a large number of candidates? Even where
each had large number of candidates, the intersection may
actually be quite small. What matters is how many candidates
the whole filter has and that's what the HEAD code limits.
Why is more needed?
At 12:08 AM 2001-11-21, you wrote:
>Jeremy Mortis wrote:
>> We are running a very large LDAP database, and I've noticed that
>> substring searches less than 4 characters, e.g. cn=*ab*, result in a
>> full scan of the database. These can be limited with the timelimit, of
>> course, but meanwhile the server gets bogged down.
>> What I'd like it to do is detect this in the filter parsing stage and
>> either return an error message or transform it into a filter that
>> quickly results in returning 0 entries.
>> Does anyone have any ideas of how this might be done, or any better
>I have a patch that does exactly this (it applies to HEAD only).
>I never committed it because after discussions it came out it
>would have been of little use. Your mail seems to change things
>a little. I can give you the patch; if you think it fits, then
>I'll commit it to HEAD code. It fits into a more general highly
>granular limitation of the search operations that will probably
>ship with 2.1. In servers/slapd/limits.c there's a comment saying
>how to configure it. Basically you can decide to limit filter
>types to certain DNs in almost the same way you do with ACLs,
>but this check is done BEFORE the search is performed; e.g. you
>may allow ".*" to use only "pres" and "eq" filters, but not
>"sub" or "approx". There's no such granularity to control the
>length of a substring, but it can be easily added if needed.
>Dr. Pierangelo Masarati | voice: +39 02 2399 8309
>Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
>Politecnico di Milano | mailto:email@example.com
>via La Masa 34, 20156 Milano, Italy |