Bug 36169 - Tree root contains itself in UDM LDAP directory module
Tree root contains itself in UDM LDAP directory module
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.0
Assigned To: Stefan Gohmann
Arvid Requate
http://www.openldap.org/its/index.cgi...
: interim-3
Depends on:
Blocks: 38424
  Show dependency treegraph
 
Reported: 2014-10-14 21:11 CEST by Florian Best
Modified: 2016-05-10 12:30 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
test.py (362 bytes, text/x-python)
2014-10-14 21:11 CEST, Florian Best
Details
Screenshot (30.64 KB, image/png)
2014-10-14 21:13 CEST, Florian Best
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2014-10-14 21:11:38 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:
[]
Comment 1 Florian Best univentionstaff 2014-10-14 21:13:56 CEST
Created attachment 6163 [details]
Screenshot

Attached is a screenshot to see how this looks then.
Comment 2 Florian Best univentionstaff 2014-10-16 16:27:56 CEST
Also for DHCP entries (see in LDAP directory)
Comment 3 Erik Damrose univentionstaff 2014-10-17 16:33:13 CEST
The container "univention" does also contains itself recursively.
Comment 4 Stefan Gohmann univentionstaff 2014-10-20 20:43:57 CEST
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:~#
Comment 5 Stefan Gohmann univentionstaff 2014-10-20 20:49:14 CEST
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.
Comment 6 Stefan Gohmann univentionstaff 2014-10-20 21:39:43 CEST
I've changed it in uldap.py: r54687

Changelog: r54688

Arvid, any concerns?
Comment 7 Arvid Requate univentionstaff 2014-10-21 14:04:00 CEST
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.
Comment 8 Alexander Kläser univentionstaff 2014-10-27 13:24:49 CET
(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?
Comment 9 Arvid Requate univentionstaff 2014-10-29 16:09:33 CET
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.
Comment 10 Arvid Requate univentionstaff 2014-10-29 16:18:16 CET
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.
Comment 11 Arvid Requate univentionstaff 2014-10-30 18:28:53 CET
The upstream patch for this issue will be integrated via Bug 36343.
Changelog Ok.
Comment 12 Stefan Gohmann univentionstaff 2014-11-26 06:55:42 CET
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".