[Date Prev][Date Next]
(ITS#5813) limits with empty dn mostly do not work
Full_Name: Hallvard B Furuseth
Version: HEAD, RE24
Submission from: (NULL) (126.96.36.199)
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
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:-)
I knew there was an issue about these limits I had forgotten.