Bug 640027
| Summary: | Naming attribute with a special char sequence parsing bug | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Andrey Ivanov <andrey.ivanov> | ||||
| Component: | Database - Indexes/Searches | Assignee: | Noriko Hosoi <nhosoi> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 1.2.6 | CC: | benl, nkinder, rmeggins, sramling | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-01-03 19:54:12 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 576869, 636700, 639035 | ||||||
| Attachments: |
|
||||||
Thanks, Andrey. It's a bug... Although '+' is escaped, the normalizer is thinking it's a separator in the RDN. :( Hi Noriko. I thought the same thing about '+' but as i said it works only in the case '+=' followed by ';'. '+' itself is ok... Hi Andrey. Thanks for the quick input! Hmmm, the dn normalizer is confused more than I thought... Since you provided me the perl script to reproduce the bug, I have the duplicated case handy. (Thanks!) Let me go through the code... Created attachment 451775 [details]
git patch file (master)
Description: When DN is made from RDNs containing escaped plus
"\+", the dn normalizer considers the value could be nested multi-
valued RDNs. (e.g., cn=C\=Z\+A\=X\+B\=Y\,o\=O,o=OO)
In that case, multi-valued RDNs are sorted by the normalizer.
(==> cn=A\=X\+B\=Y\+C\=Z\,o\=O,o=OO)
The sample DN provided by Andrey Ivanov contains "\+", but that
is not a separator for the multi-valued RDNs:
cn=mytest\+\=-123'\;456,dc=example,dc=com
The dn normalizer should have checked the possibility, as well.
The check is added in this patch.
Also, sorting was not triggered if multi-valued RDNs are located
at the end of the value. (e.g., cn=C\=X\,B\=Y\+A\=Z,o=OO)
The bug was fixed, as well.
File: ldap/servers/slapd/dn.c
Reviewed by Nathan (Thank you!!). Pushed to master. $ git merge 640027 Updating c783496..9a00a44 Fast-forward ldap/servers/slapd/dn.c | 56 +++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 50 insertions(+), 6 deletions(-) $ git push Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.43 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git c783496..9a00a44 master -> master Pushed to Directory_Server_8_2_Branch. Counting objects: 29, done. Delta compression using up to 2 threads. Compressing objects: 100% (21/21), done. Writing objects: 100% (21/21), 4.23 KiB, done. Total 21 (delta 15), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 1176d3f..975f86c ds82-local -> Directory_Server_8_2_Branch Bug verified with the redhat-ds-base 8.2.3 build. Steps to verify. 1. Add users from the ldif file. dn: cn=mytest\2B\3D-123'\3B456,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person sn: Last Name givenName: First Name cn: mytest+=-123';456 dn: cn=C\=Z\+A\=X\+B\=Y\,o\=O\,o=OO,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person sn: Last Name givenName: First Name cn: C=Z+A=X+B=Y,o=O,o=OO dn: cn="cn=A, ou=B, o=C", dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person sn: Last Name givenName: First Name cn: "cn=A, ou=B, o=C" 2. Check whether the corresponding entries added to the LDAP. 3. Result: Successfully adds the corresponding entries as per the ldif file. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0003.html |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 adding an entry with a naming attribute value similar to "mytest+=-123';456" gives a strange result. Reproducible: Always Steps to Reproduce: 1. Create a simple LDAP database for "dc=example,dc=com" 2. Use the following perl script : #!/usr/bin/perl use Net::LDAP; use Net::LDAP::Search; use Net::LDAP::Util qw(escape_filter_value escape_dn_value); use Data::Dumper; my $ldap = Net::LDAP->new('localhost', port => 389, version => 3) or die "error LDAP: Impossible to contact the server ($@)"; $ldap -> bind ( "cn=Directory Manager", password => 'secret' ); my $cn="mytest+=-123';456"; my $new_ldap_entry = Net::LDAP::Entry -> new(); print "escaped value is: cn=".escape_dn_value($cn).",dc=example,dc=com\n"; $new_ldap_entry -> dn('cn='.escape_dn_value($cn).",dc=example,dc=com"); $new_ldap_entry -> add( 'objectClass' => 'top', 'objectClass' => 'inetOrgPerson', 'sn' => 'Last Name', 'givenName' => 'First Name', # 'cn' => 'lala', # 'cn' => $cn, ); print Dumper($new_ldap_entry); my $mesg = $new_ldap_entry -> update($ldap); __END__ 3. search for the added LDAP entry (with ldapsearch of openldap, for example): # \3D-123'\2Bmytest\3B456, example.com dn: cn=\3D-123'\2Bmytest\3B456,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person sn: Last Name givenName: First Name cn: =-123'+mytest;456 # search result search: 2 result: 0 Success Actual Results: We can see that the added CN does not correspond the given CN. You can try decommenting the lines in perl script to add to the entry the values $cn or 'lala', it just adds a second value of the cn. Expected Results: the cn and dn should correspond to the ones in script. Some interesting notes: if i delete the ';' in the cn everything is fine : # mytest\2B\3D-123'456, example.com dn: cn=mytest\2B\3D-123'456,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person sn: Last Name givenName: First Name cn: mytest+=-123'456 If i delete the '+' everything is also fine. If i delete '=' everything is fine again :) I think it's the sequence '+=' and then ';' that causes this sort of behavior. Don't know whether it's a bug or it is a "normal" behavior according to the RFCs. I'm however inclined to consider it a bug :)