Bug 640027

Summary: Naming attribute with a special char sequence parsing bug
Product: [Retired] 389 Reporter: Andrey Ivanov <andrey.ivanov>
Component: Database - Indexes/SearchesAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: low Docs Contact:
Priority: high    
Version: 1.2.6CC: 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:
Bug Depends On:    
Bug Blocks: 576869, 636700, 639035    
Attachments:
Description Flags
git patch file (master) nkinder: review+

Description Andrey Ivanov 2010-10-04 15:18:39 UTC
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 :)

Comment 1 Noriko Hosoi 2010-10-04 17:57:34 UTC
Thanks, Andrey.  It's a bug...

Although '+' is escaped, the normalizer is thinking it's a separator in the RDN. :(

Comment 2 Andrey Ivanov 2010-10-04 18:02:34 UTC
Hi Noriko. I thought the same thing about '+' but as i said it works only in the case '+=' followed by ';'. '+' itself is ok...

Comment 3 Noriko Hosoi 2010-10-04 18:12:03 UTC
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...

Comment 4 Noriko Hosoi 2010-10-05 23:16:30 UTC
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

Comment 6 Noriko Hosoi 2010-10-06 00:55:53 UTC
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

Comment 7 Nathan Kinder 2010-12-09 19:52:57 UTC
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

Comment 9 Sankar Ramalingam 2010-12-22 12:04:05 UTC
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.

Comment 11 errata-xmlrpc 2011-01-03 19:54:12 UTC
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