Re: Limiting filter types based on op_ndn

[Pierangelo Masarati <masarati@aero.polimi.it>]

> 
> 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 

dn: ^$

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

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, 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 :( )

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.

> 
> 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.
However, this could be misleading, because '(cn=a*)' Undefined
could be interpreted as there's no 'cn' starting with 'a',
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.

Pierangelo.