Bug 640027 - Naming attribute with a special char sequence parsing bug
Summary: Naming attribute with a special char sequence parsing bug
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: 389
Classification: Retired
Component: Database - Indexes/Searches
Version: 1.2.6
Hardware: x86_64
OS: Linux
high
low
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.7 636700 639035
TreeView+ depends on / blocked
 
Reported: 2010-10-04 15:18 UTC by Andrey Ivanov
Modified: 2015-01-04 23:44 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-03 19:54:12 UTC


Attachments (Terms of Use)
git patch file (master) (7.06 KB, patch)
2010-10-05 23:16 UTC, Noriko Hosoi
nkinder: review+
Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0003 normal SHIPPED_LIVE redhat-ds-base bug fix update 2011-01-03 19:54:07 UTC

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


Note You need to log in before you can comment on or make changes to this bug.