In reading through the documentation for Fedora DS, I saw an
interesting feature where you can, at the slapd level, disable the
ability for clients to execute filters when the attribute(s) being
filtered on are not indexed.
What's the motivation for this? I've thought about suggesting similar
features (or maybe even suggested it, I don't remember) - but so far
the "unchecked" limit has proved a better way for my purposes.
How does it work with complex filters? E.g. (&(cn=foo)(mail=*))
where cn is indexed and finds the relevant entries, mail=*
eliminates the 0.1% mailless users. Should this succeed if mail
has no presence index? If no, what's the advantage of forbidding
it? If yes, how do you stop (&(objectClass=person)(mail=*))?
This seems an interesting feature to me, but I think it could be
more worthwhile to make it a bit more configurable, (...)
For example, I may want to block subfinal indices on the
"suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.
I can see an access control reason for doing that, though users
might get trivially around it by appending a '*' to the filter.
And I do use sizelimit and the "unchecked" limit as a crude form of
access control, as well as to ensure a good response time. But it
remains crude, since it's not what an index is for - it's basically
just an optimization.