Univention Bugzilla – Bug 36169
Tree root contains itself in UDM LDAP directory module
Last modified: 2016-05-10 12:30:25 CEST
Created attachment 6162 [details] test.py The attached code has different results in UCS4 and UCS 3.2. This causes that the Tree in the LDAP-Directory-Browser module shows itself as first element again. In UCS4.0: [<univention.admin.handlers.container.dc.object object at 0x35fdb10>] In UCS3.2: []
Created attachment 6163 [details] Screenshot Attached is a screenshot to see how this looks then.
Also for DHCP entries (see in LDAP directory)
The container "univention" does also contains itself recursively.
UCS 3.2: root@ucs-3904:~# univention-ldapsearch -s base objectClass=univentionBase -LLL dn dn: dc=deadlock32,dc=intranet root@ucs-3904:~# univention-ldapsearch -s one objectClass=univentionBase -LLL dn root@ucs-3904:~# UCS 4.0: root@master501:~# univention-ldapsearch -s base objectClass=univentionBase -LLL dn dn: dc=deadlock50,dc=intranet root@master501:~# univention-ldapsearch -s one objectClass=univentionBase -LLL dn dn: dc=deadlock50,dc=intranet root@master501:~#
After switching back from MDB to BDB: root@master501:~# univention-ldapsearch -s one objectClass=univentionBase -LLL dn root@master501:~# univention-ldapsearch -s base objectClass=univentionBase -LLL dn dn: dc=deadlock50,dc=intranet root@master501:~# So, it seems to be a problem with the MDB backend.
I've changed it in uldap.py: r54687 Changelog: r54688 Arvid, any concerns?
Quoting http://www.openldap.org/doc/admin24/access-control.html: "children matches all entries under the DN (but not the entry named by the DN)." So I guess "one" is supposed to include the base DN. I checked: univention-ldapsearch -xLLL -s children objectClass=univentionBase dn works with both bdb and mdb.
(In reply to Arvid Requate from comment #7) > Quoting http://www.openldap.org/doc/admin24/access-control.html: > > "children matches all entries under the DN (but not the entry named by the > DN)." > > So I guess "one" is supposed to include the base DN. > > > I checked: > > univention-ldapsearch -xLLL -s children objectClass=univentionBase dn > > works with both bdb and mdb. Does that mean that the old behaviour (i.e., with the previous backend) was incorrect? Might this change lead to problems in other places?
First I revoke my Comment 7: The scope "children" is something different. It means "subordinate" (according to draft-sermersheim-ldap-subordinate-scope) and is equivalent to "subtree without base". > Does that mean that the old behaviour (i.e., with the previous backend) > was incorrect? No, the new one is incorrect, thanks for asking.. I filed an upstream bug report http://www.openldap.org/its/index.cgi/Incoming?id=7975 > Might this change lead to problems in other places? Yes, e.g. I would expect "base+one" in univention.uldap to return the base object twice as well.
Just note that other code using SCOPE_ONELEVEL searches may show a change of behaviour too. From a quick grep I see these candidates: univention-licence/lib/license_ldap.c univention-python/uldap.py univention-python/modules/uldap.py univention-directory-listener/src/filter.c univention-directory-listener/tests/test__filter__cache_entry_ldap_filter_match.c univention-directory-manager-modules/scripts/proof_uniqueMembers But the issue only occurs if a filter was specified for a scope "one" search, which only matches the base of the search and none of the children.
The upstream patch for this issue will be integrated via Bug 36343. Changelog Ok.
UCS 4.0-0 has been released: http://docs.univention.de/release-notes-4.0-0-en.html http://docs.univention.de/release-notes-4.0-0-de.html If this error occurs again, please use "Clone This Bug".