From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 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: Always 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 ...Bound... ===========================> Initial entry DN: cn=BeforeSlash\\AfterSlash,ou=objets,dc=id,dc=polytechnique,dc=edu ------------------------------------------------------------------------ dn:cn=BeforeSlash\\AfterSlash,ou=objets,dc=id,dc=polytechnique,dc=edu objectClass: top person 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 nique,dc=edu modifiersName: uid=andrey.ivanov,ou=personnel,ou=utilisateurs,dc=id,dc=polytec hnique,dc=edu createTimestamp: 20080319100354Z modifyTimestamp: 20080319100354Z ==> /Logs/Ldap/access <== [19/Mar/2008:11:03:54 +0100] conn=76 fd=130 slot=130 connection from 129.104.69.50 to 129.104.69.50 [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
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