Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) 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. This seems an interesting feature to me, but I think it could be more worthwhile to make it a bit more configurable, where you could block certain filter types from being used, regardless of whether or not they were indexed, and expanded to only pertain to particular subtrees. For example, I may want to block subfinal indices on the "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. Just food for thought. --Quanah
quanah@OpenLDAP.org writes: > 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. -- Regards, Hallvard
quanah@OpenLDAP.org writes: > For example, I may want to block subfinal indices on the > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. I should have added: Unless you've got a better answer than me for why this is better than the "unchecked" limit, it might be more useful to block "suAffiliation" from getting a "subfinal" index. Then use the "unchecked" limit to block too general searches. -- Regards, Hallvard
----- "h b furuseth" <h.b.furuseth@usit.uio.no> wrote: > quanah@OpenLDAP.org writes: > > For example, I may want to block subfinal indices on the > > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. > > I should have added: Unless you've got a better answer than me for > why this is better than the "unchecked" limit, it might be more > useful to block "suAffiliation" from getting a "subfinal" index. > Then use the "unchecked" limit to block too general searches. Hi Hallvard, My reasoning comes from this: At my previous job we had a tree rooted at "dc=stanford,dc=edu". Controlling the indexing to allow/block certain types of searches has been very important, and the directory well tuned to that purpose. The following subtrees are what exist: cn=people, cn=accounts, and cn=organizations. cn=organizations is the newest subtree, and additional indexing had to be added on attributes that used to be indexed differently in the person tree. There is no desire to split the trees apart into their own databases, but indexing is per database (not per subtree). For example, displayName used to be indexed "eq" only. Now with organizations, we need to change the index to "eq,sub". So it would be nice to block substring filters of displayName in the cn=people tree, etc. --Quanah
quanah@zimbra.com wrote: > ----- "h b furuseth" <h.b.furuseth@usit.uio.no> wrote: >> quanah@OpenLDAP.org writes: >>> For example, I may want to block subfinal indices on the >>> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. >> I should have added: Unless you've got a better answer than me for >> why this is better than the "unchecked" limit, it might be more >> useful to block "suAffiliation" from getting a "subfinal" index. >> Then use the "unchecked" limit to block too general searches. > > Hi Hallvard, > > My reasoning comes from this: At my previous job we had a tree rooted at "dc=stanford,dc=edu". Controlling the indexing to allow/block certain types of searches has been very important, and the directory well tuned to that purpose. The following subtrees are what exist: cn=people, cn=accounts, and cn=organizations. cn=organizations is the newest subtree, and additional indexing had to be added on attributes that used to be indexed differently in the person tree. There is no desire to split the trees apart into their own databases, but indexing is per database (not per subtree). > > For example, displayName used to be indexed "eq" only. Now with organizations, we need to change the index to "eq,sub". So it would be nice to block substring filters of displayName in the cn=people tree, etc. > > --Quanah Should be simple enough to write an overlay that can be configured with a URI and filter types to block. Just return Unwilling to Perform for any matching patterns. Certainly not something that needs to be added to the core code. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes moved from Incoming to Software Enhancements
request for enhancement