Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: http://folk.uio.no/hbf/OpenLDAP/limits-empty.txt Submission from: (NULL) (129.240.6.233) Submitted by: hallvard
Limits set as limits dn.<exact/base/onelevel/subtree/children>="" ... are never used: - exact/base: it only matches the empty Bind DN, which in slapd means anonymous, for which limits_get() does not test dn.<exact/base>. - onelevel/subtree/children: limits_get() does not use these for the empty Bind DN, and it expects a non-empty Bind DNs to end with ",".
Some cases above work with dn.this.foo instead of dn.foo. limits dn.regex="" works (equivalent to limits users). limits dn.group="" may work if the admin stuffs group members into the root DSE. (I haven't tested.)
My preferred fixes:
- For dn.this, fix the above since baseDN "" makes sense and dn.this is new anyway, so there is no backwards compatibility to worry about.
- For dn.self, fail parsing of the limit cases above that do not work.
Otherwise the dn.this change could invoke new functionality in existing configurations. We won't know what the admin meant with DN "" - did he mean to include anonymous? That is not an entry with a DN, but is stored in slapd and the Bind request as the empty DN.
Also limits parsing vs. anonymous connections is dubious today anyway: dn.<anything>=* or dn.regex=.* are special-cased to match anonymous, while dn="" does not. Also dn.children=* should not match anonymous but does.
So it seems to me that any cleanup should consist of first removing strange cases, and if anyone want them reintroduce them in a later branch with correct semantics.
I enclose a suggested fix. Giving Pierangelo at least time to repond since he either agreed or disagreed with this in this message, I'm not sure which:-) http://www.openldap.org/lists/openldap-devel/200810/msg00116.html I knew there was an issue about these limits I had forgotten.