[Date Prev][Date Next]
Re: (ITS#4942) configurable filter blocking
> 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.