Re: Limiting filter types based on op_ndn

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

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

well, at candidate selection the index IS effective
in negating the indexed candidates out of ALLIDS.

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

In this case, as well as in the previous one, a low
profile user's query that passes thru the filter check
may be captured by a small candidate limit check

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

Definitely. Note that the candidate limit check is already
implemented and should be used in conjunction with this
checking to trap the tricky cases you're highlighting ...

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

That's a good point. We're moving towards that solution;
however, we'd still like to trap unqualified or low profile
users while allowing large margins to everyday applications.
I'm talking about that sort of apps that are not resource 
intensive (no web auth or mail routing: these definitely
need dedicated servers) but that may need to do large queries
every now and then: build employee hierarchy offline by downloading
the whole DS every half an hour, or so. The nasty side is that
the DS administrators will have very little control on these
folks, while they're always complaining because "they launched
their monster app three times simultaneously and the DS is
not responding quickly enough".

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

See above.

Another need is, waiting for LCUP, to have
nearly unlimited read access for some agents that synchronize
different directories (our async metadirectory). At present
we needed to use the rootdn to be able to enforce some rough
size/time limit on normal users (before I added the per o_ndn 
size/time checks). This is not a clean solution, because the
rootdn also has unlimited write access.

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

Well, this way a user would not be authorized/unauthorized: there
would be some way between, he/she would be authorized on some filters only.
Here the user might be allowed to search on 'cn' but only with, say, 
equality filters.

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

That's exactly what I meant; I noticed your note :)

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

DoS would be an excessive term, I mean unintended DoS like unbound people 
playing with '*' in Netscape's address book or so while bound people 
(the boss?) need be allowed to do that.

To come to a conclusion, I'm not sure yet as if this is useful or not.
I'm still playing with it. Maybe I find out that I'm never going to 
take advantage of it and I'll drop it. But, as soon as it is there,
if there is any interest I'll check it in.

Pierangelo.