Re: Limiting filter types based on op_ndn

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:24 PM 2001-09-22, Pierangelo Masarati wrote:
>> 
>> I might be a bit confused as to actually what you are suggesting,
>> (maybe an example would be useful), but...
>
>e.g., assuming 'uid' has only pres,eq indices:
>
>dn: cn=Ando, ou=People, dc=OpenLDAP, dc=org
>
>can use '(uid=*)' (presence) and '(uid=a*)' (substring)
>'(uid=xxxx)' (equality) and '(uid>=p*)' (ordering), so
>'uid=ando' can do maintenance, statistics and heavy 
>queries but
>
>dn: .*, ou=Guests, dc=OpenLDAP, dc=org
>
>can do only '(uid=*)' (presence) and '(uid=xxxx)' (equality),
>i.e. they can only use indicized queries, and 

But say the user does (!(uid=*)) ?  uid is indexed, but
ineffective.


>dn: ^$
>
>(anonymous) can only use '(uid=xxxx)' (equality) which means 
>they can only fetch one entry at a time.

What about (!(uid=xxxx)) ?


>What I'm trying to implement is some way of denying
>very heavy queries on non-indexed attributes with the 
>least cost on the server side,

As shown above, a user can construct a filter using
index attributes which still result in large number
of candidates.

>because we want to maintain
>the least possible number of indices for write performances
>(I know LDAP is WORM, but very often we have MANY writes
>nearly simultaneous that slow down the master and the slaves,
>occasionally leading to index corruption :( )

One thing you can do is setup the master with limited
indices (maybe just objectClass eq) and reduce the
canditiate limit to 1.  This effectively restricts the
master to read + update operations.  Then shift all the
non-base search operations to slaves (with appropriate indices).

>On the other hand, I have many applicative DNs that need 
>to do heavy duty work, so I cannot deny in a non-selective
>manner, like cutting queries that result in too many candidates.

Another suggestion is to have slave(s) dedicated to these
applications and for them to only access the master when they
need to update an entry.

>> 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?
>
>I didn't consider the possibility of making them Undefined.

Note "as opposed" referred to the current behavior of slapd.

>However, this could be misleading, because '(cn=a*)' Undefined
>could be interpreted as there's no 'cn' starting with 'a',

That happens all the time.  The user may not be authorized to
access cn and hence (cn=a*) is Undefined for a particular target
entry.

>while UnwillingToPerform would be clear: the server is not going
>to give a result for this request.

>Anyway, I didn't consider whether the behavior I'm working at 
>would violate some RFCs on 'politeness' of DSAs or not. 
>I hope there's enough freedom to implementors to inhibit or 
>restrict ops at will, provided an appropriate result is returned.

Well, as I recently noted on the LDAPbis list, a server can
refuse to perform any request for any reason and is only
obligated to respond in an appropriate manner.

I'm more concerned about the general usefulness of the feature.
Namely, it is unclear to me whether the feature would be
effective in defeating DoS attacks (or even attack by naive users).