OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/5813
Full headers

From: h.b.furuseth@usit.uio.no
Subject: limits with empty dn mostly do not work
Compose comment
Download message
State:
0 replies:
0 followups:

Major security issue: yes  no

Notes:

Notification:


Date: Sun, 16 Nov 2008 07:43:09 GMT
From: h.b.furuseth@usit.uio.no
To: openldap-its@OpenLDAP.org
Subject: limits with empty dn mostly do not work
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.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org