Bug 438139

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.

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 1.2.20.11.2.35, 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.

----------------------------
revision 1.2.20.11.2.35
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.
----------------------------

Created attachment 327046 [details]
cvs diff of dn.c checked in on 9 Oct '00

Created attachment 328240 [details]
cvs diffs

Files:
ldapserver/ldap/servers/slapd/slapi-private.h
                             /ava.c
                             /dn.c
                             /util.c

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.

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
	        16: 	
	        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.

Created attachment 328242 [details]
shell test script

Created attachment 328328 [details]
cvs commit message

Reviewed by Rich (Thank you!!)

Checked in into CVS HEAD.

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

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/RHEA-2009-0455.html