Bug 438139 - DN with antislash('\') rename (modrdn) problem
Summary: DN with antislash('\') rename (modrdn) problem
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
Reported: 2008-03-19 12:01 UTC by Andrey Ivanov
Modified: 2015-01-04 23:31 UTC (History)
5 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-29 23:03:16 UTC

Attachments (Terms of Use)
Script to reproduce the MODRDN problem (3.04 KB, application/octet-stream)
2008-03-19 12:04 UTC, Andrey Ivanov
no flags Details
cvs diff of dn.c checked in on 9 Oct '00 (3.04 KB, patch)
2008-12-16 00:41 UTC, Noriko Hosoi
no flags Details | Diff
cvs diffs (10.96 KB, patch)
2009-01-06 00:00 UTC, Noriko Hosoi
no flags Details | Diff
Modified perl test script (5.37 KB, text/plain)
2009-01-06 00:09 UTC, Noriko Hosoi
no flags Details
shell test script (3.27 KB, text/plain)
2009-01-06 00:10 UTC, Noriko Hosoi
no flags Details
cvs commit message (1.93 KB, text/plain)
2009-01-06 22:52 UTC, Noriko Hosoi
no flags Details

Description Andrey Ivanov 2008-03-19 12:01:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080201 Firefox/

Description of problem:
The FDS returns LDAP_OPERATIONS_ERROR ('Server encountered an internal error') while trying to rename an entry containing an RDN with antislash (\). The addentry/add/mod/del/entrydelete operations on this entry are processed correctly.

It is also possible that after several add/mod/del/rdn operations on this type of entries the consistency of id2entry is also compromised (this second problem is not reproducible each time).

Version-Release number of selected component (if applicable):
FDS 1.1.0

How reproducible:

Steps to Reproduce:
1. Use the attached perl script to reproduce the "internal server error". The script creates an entry with '\' in the RDN (correctly escaped). This entry can be searched/compared/deleted correctly. However if we try to rename it (change dn with the modrdn) a server internal error is produced.
2. After several add/modrdn/deletes on this types of entries i had the ldap error log messages like "the id is present in smth but not in id2entry" or "smth is present in id2entry but not in..." which seems to indicate an inconsistency of the maintenance of id2entry indexes. I could not reproduce this particular problem each time so it is less important or may have the same origin as the first one.

Actual Results:
[root@ldap-model Updates]# ./SlashBug.pl 
Binding with SASL

===========================> Initial entry DN: cn=BeforeSlash\\AfterSlash,ou=objets,dc=id,dc=polytechnique,dc=edu

objectClass: top
         sn: Last Name
         cn: BeforeSlash\AfterSlash

===========================> Error, program part: Renaming the entry
        Error : Operations error
        Error name : LDAP_OPERATIONS_ERROR
        Error text : Server encountered an internal error
        Error description : Operations error
Operations error at ./SlashBug.pl line 29, <DATA> line 502.

Expected Results:
The entry should be correctly renamed or a more explicative error should be returned. The (possible) inconsistency of id2entry should not appear in any case.

Additional info:
The contents of LDAP log files :
==> /Logs/Ldap/audit <==
time: 20080319110354
dn: cn=BeforeSlash\\AfterSlash,ou=objets,dc=id,dc=polytechnique,dc=edu
changetype: add
objectClass: top
objectClass: person
sn: Last Name
cn: BeforeSlash\AfterSlash
creatorsName: uid=andrey.ivanov,ou=personnel,ou=utilisateurs,dc=id,dc=polytech
modifiersName: uid=andrey.ivanov,ou=personnel,ou=utilisateurs,dc=id,dc=polytec
createTimestamp: 20080319100354Z
modifyTimestamp: 20080319100354Z

==> /Logs/Ldap/access <==
[19/Mar/2008:11:03:54 +0100] conn=76 fd=130 slot=130 connection from to
[19/Mar/2008:11:03:54 +0100] conn=76 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[19/Mar/2008:11:03:54 +0100] conn=76 op=0 RESULT err=14 tag=97 nentries=0 etime=0.004000, SASL bind in progress
[19/Mar/2008:11:03:54 +0100] conn=76 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[19/Mar/2008:11:03:54 +0100] conn=76 op=1 RESULT err=14 tag=97 nentries=0 etime=0.000000, SASL bind in progress
[19/Mar/2008:11:03:54 +0100] conn=76 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[19/Mar/2008:11:03:54 +0100] conn=76 op=2 RESULT err=0 tag=97 nentries=0 etime=0.001000 dn="uid=andrey.ivanov,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu"
[19/Mar/2008:11:03:54 +0100] conn=76 op=3 ADD dn="cn=BeforeSlash\5c\5cAfterSlash,ou=objets,dc=id,dc=polytechnique,dc=edu"
[19/Mar/2008:11:03:54 +0100] conn=76 op=3 RESULT err=0 tag=105 nentries=0 etime=0.002000
[19/Mar/2008:11:03:54 +0100] conn=76 op=4 SRCH base="ou=objets,dc=id,dc=polytechnique,dc=edu" scope=1 filter="(&(objectClass=person)(cn=BeforeSlash\5cAfterSlash))" attrs="*"
[19/Mar/2008:11:03:54 +0100] conn=76 op=4 RESULT err=0 tag=101 nentries=1 etime=0.001000
[19/Mar/2008:11:03:54 +0100] conn=76 op=5 MODRDN dn="cn=BeforeSlash\5c\5cAfterSlash,ou=objets,dc=id,dc=polytechnique,dc=edu" newrdn="cn=WithoutSlash" newsuperior="(null)"
[19/Mar/2008:11:03:54 +0100] conn=76 op=5 RESULT err=1 tag=109 nentries=0 etime=0.000000
[19/Mar/2008:11:03:54 +0100] conn=76 op=-1 fd=130 closed - B1

Comment 1 Andrey Ivanov 2008-03-19 12:04:29 UTC
Created attachment 298496 [details]
Script to reproduce the MODRDN problem

Adapt the script to your server/authentification type. In our environment it is
GSSAPI bind.

Comment 3 Noriko Hosoi 2008-12-16 00:26:18 UTC
The cause of the LDAP_OPERATIONS_ERROR error was introduced by this fix made in the year 2000.  The change log below claims modrdn fails if the RDN includes backslash '\' in it.  But we are observing the opposite.  I'm attaching the diff checked in for, where '\' is removed from RDN. The change makes the RDN mismatch the RDN in the database and modrdn fails.  By reversing the change, modrdn works.

date: 2000/10/10 11:22:53;  author: mares;  state: Exp;  lines: +75 -0
Bug: 515715, 394800
Reviewed by: Mark Wahl (as a part of the fix, the new function has been named st
rcpy_unescape_dnvalue as suggested by him)
Files: slapd/dn.c

Bug description: Impossible to modify any entry that was renamed sometime in the past and their new RDN contains a special character that needs to be scaped like semicolon"\;"
Test method : Manual
Platform: Solaris 2.6 (build & execute). NT (build)
Fix description: The new rdn attribute was being wrongly introduced in the entry still containing the scape character "\". We need to make sure that such characters get removed at the attribute storage level.

Comment 4 Noriko Hosoi 2008-12-16 00:41:08 UTC
Created attachment 327046 [details]
cvs diff of dn.c checked in on 9 Oct '00

Comment 5 Noriko Hosoi 2009-01-06 00:00:59 UTC
Created attachment 328240 [details]
cvs diffs


Problem description:
Unescape codes in the DS (strcpy_special_undo in ava.c and strcpy_unescape_dnvalue in dn.c) were "unescaping" more than the escape code (e.g., escape_dn_value in NET LDAP).  The test string 'BeforeSlash\AfterSlash' fortunately/unfortunately contains '\Af', which is considered '\##' (where # is hex number) by the DS unescape functions even though it was not meant to be escaped.  As long as using UTF-8, there is no chance for the server to receive "\af".

Change description:
1) There were identical static functions: strcpy_special_undo (ava.c) and strcpy_special_undo (dn.c).  Merged them to strcpy_unescape_value and put it in util.c.
2) In the unescape/normalize functions for dn (strcpy_unescape_value in util.c and substr_dn_normalize in dn.c), added a check for the first hex number in '\##'.  If the 8th bit is on, we don't do unescaping but store it as is since the unescaped character is not UTF-8.
3) If 2 consecutive '\'s are passed to the unescape/normalize functions, keep one of them.

Comment 6 Noriko Hosoi 2009-01-06 00:09:01 UTC
Created attachment 328241 [details]
Modified perl test script

Usage: perl SlashBug.pl <port> <base dn> <root pw> <test str #>
	      port: 389 (default)
	   base dn: dc=example,dc=com (default)
	   root pw: password (default)
	test str #:
	         0: BeforeSlash\AfterSlash (default)
	         1: BeforeSlashAfterSlash
	         2: abc\txyz
	         3: abc	xyz
	         4: A\7AXYZ
	         5: AAXYZ
	         6: B\7AXYZ
	         7: B\7AXYZ
	         8: C\\7AXYZ
	         9: C\\7AXYZ
	        10: a,b,c x;y;z
	        11: a,b,c x;y;z
	        12: a"b"c x+y+z
	        13: a\b\c x=y=z
	        14: `x=y=z
	        15: \00\11\22\33
	        17: A\B+C"D,E;F=G<H>I#J
	        18: Violents combats à Gaza, Israël rejette les appels à une trêve

Notes: the test includes unprintable characters.
The test is supposed to cover the special characters listed in http://www.ietf.org/rfc/rfc2253.txt.

Comment 7 Noriko Hosoi 2009-01-06 00:10:21 UTC
Created attachment 328242 [details]
shell test script

Comment 8 Noriko Hosoi 2009-01-06 22:52:15 UTC
Created attachment 328328 [details]
cvs commit message

Reviewed by Rich (Thank you!!)

Checked in into CVS HEAD.

Comment 9 Jenny Severance 2009-03-12 19:55:44 UTC
fix verified DS 8.1 RHEL 5

[root@jennyv2 jenny]# ./bug438139.sh 
port: 389
basedn: ou=people,dc=bos,dc=redhat,dc=com
rootdn password: Secret123
ldap_delete: No such object
ldap_delete: matched: ou=people,dc=bos,dc=redhat,dc=com
add an entry: dn: uid=test_user000, ou=people,dc=bos,dc=redhat,dc=com
adding new entry uid=test_user000, ou=people,dc=bos,dc=redhat,dc=com

PASS: uid=test_user000 is found
modrdn the entry: dn: uid=test_user000, ou=people,dc=bos,dc=redhat,dc=com --> dn: uid=test_user\000, ou=people,dc=bos,dc=redhat,dc=com
modifying RDN of entry uid=test_user000, ou=people,dc=bos,dc=redhat,dc=com

PASS: uid=test_user\000 is found
modrdn the entry: dn: uid=test_user\000, ou=people,dc=bos,dc=redhat,dc=com --> dn: uid=test_user\\111, ou=people,dc=bos,dc=redhat,dc=com
modifying RDN of entry uid=test_user\000, ou=people,dc=bos,dc=redhat,dc=com

PASS: uid=test_user\\111 is found
modrdn the entry:  --> dn: uid=test_user\;, ou=people,dc=bos,dc=redhat,dc=com
modifying RDN of entry uid=test_user\\111, ou=people,dc=bos,dc=redhat,dc=com

PASS: uid=test_user\; is found
modrdn the entry: dn: uid=test_user\;, ou=people,dc=bos,dc=redhat,dc=com --> dn: uid=test_user\", ou=people,dc=bos,dc=redhat,dc=com
modifying RDN of entry uid=test_user\;, ou=people,dc=bos,dc=redhat,dc=com

PASS: uid=test_user\" is found

Comment 10 Chandrasekar Kannan 2009-04-29 23:03:16 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.


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