Description of problem: Double quoted distinguished names do not work since fedora-ds-1.2.0. When trying to add an entry with such, the result will be wrong. Version-Release number of selected component (if applicable): fedora-ds-1.2.0 How reproducible: ALways. Steps to Reproduce: 1. Add this entry with ldapadd dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com aliasedObjectName: ou=foo,dc=test,dc=com objectClass: top objectClass: alias Observe that now, you get a schema violation because the directory tries to create aliasedObjectName: "ou=foo,dc=test,dc=com" and so you would get two aliasedObjectName which is not allowed. 2. Then disable schema validation and add the same entry. Read it back with LDAP search or by db2ldif the whole database and look at result. You have this entry: dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com aliasedObjectName: ou=foo,dc=test,dc=com aliasedObjectName: "ou=foo,dc=test,dc=com" objectClass: top objectClass: alias 3. add this entry with ldapadd. It doesn't matter if schema checking is on or off. dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com objectClass: top objectClass: alias Observe that the entry in the directory now looks like this. alaisedobjectname attribute is set from dn but with quotes: dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com aliasedObjectName: "ou=foo,dc=test,dc=com" objectClass: top objectClass: alias Actual results: See above. Expected results: No additional extra attribute with added quotes. It may be correct that the attribute has quotes but the aliases are at least not clickable in LDAP browser then. The schema violation is a side effect, because the example is aliasedobjectname class. Try it with something else like cn= and the added attribute will show up without any validation errors. Additional info: This seems to affect some internal fedora-ds tools, like password policy configuration. Also, replicating double quoted entries from another (older) directory works just fine, but when you try to export these from the new directory they come out with their original double-quoted representation so it's impossible to reimport or you get the same errors as outlined above.
Per RFC 4514, the only valid ways of representing a DN with '=' and ',' characters within an RDN attribute value are the following: aliasedObjectName=ou\3Dfoo\2Cdc\3Dtest\2Cdc\3Dcom,dc=test,dc=com aliasedObjectName=ou\=foo\,dc\=test\,dc\=com,dc=test,dc=com The old method of double-quoting a value without needing to escape characters such as ',' and '=' was obsoleted in RFC 4514 (it was previously defined in RFC 2253, section 4). That said, RFC 4514 does not block an implementation from recognizing other forms. In general, we should discourage use of the old double-quoted form as much as possible. In fact, our server scripts such as the ns-newpwpolicy.pl password policy script will use an escaped DN form now (I believe I changed this after the 1.2.0 release). I think it would be nice to still recognize the old double-quoted form, but we should convert it to the escaped form and return the escaped form in response to searches. This is in fact mentioned at the and of RFC 4514, section 3. Currently, it appears that the escaping of a double-quoted attribute is being performed as follows: input - aliasedObjectName="ou=foo,dc=test,dc=com",dc=test,dc=com escaped - aliasedObjectName=\"ou\=foo\,dc\=test\,dc\=com\",dc=test,dc=com We should be removing the double quotes instead of escaping them and making them a part of the value.
I believe that this regression was introduced by the fix for bug 438139. It appears that the strcpy_unescape_value() function (previously named strcpy_unescape_dnvalue) is not stripping leading and trailing '"' characters off of a value that is used within a DN.
Created attachment 369069 [details] Proposed Patch The bug fix for bug 438139 introduced a regression that causes the server to not handle LDAPv2 quoted RDN values correctly. We were including the '"' characters used to contain an unescaped value in the actual value itself. The proper thing to do is to eliminate any '"' characters that are not escaped when we unescape the value. I have tested this new fix with the oringinal issue from bug 438139 to ensure that it does not introduce a regression for that bug.
Patch from comment#3 pushed to master. Thanks to Rich and Noriko for their reviews! Counting objects: 11, done. Delta compression using 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.00 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 7cdc2ad..4c333c1 master -> master
verified - RHEL 4 version: 1. turned off syntaxcheck and added seeAlso attribute with double-quoted DN value # scarter, People, example.com dn: uid=scarter,ou=People,dc=example,dc=com cn: Sam Carter sn: Carter givenName: Sam objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson ou: Accounting ou: People l: Sunnyvale uid: scarter mail: scarter telephoneNumber: +1 408 555 4798 facsimileTelephoneNumber: +1 408 555 9751 roomNumber: 9999 userPassword:: e1NNRDV9ekxadFRZbk1LTFY5dkV2NzE1TnIzQ3FZMmpvPQ== userCertificate: seeAlso: "ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com <=============== 2. turned on syntaxcheck ldapsearch -x -h hostname.company.com -p 389 -D "cn=Directory Manager" -w Secret -b "cn=config" | grep syntaxcheck nsslapd-syntaxcheck: on # scarter, People, example.com dn: uid=scarter,ou=People,dc=example,dc=com cn: Sam Carter sn: Carter givenName: Sam objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson ou: Accounting ou: People l: Sunnyvale uid: scarter mail: scarter telephoneNumber: +1 408 555 4798 facsimileTelephoneNumber: +1 408 555 9751 roomNumber: 9999 userPassword:: e1NNRDV9ekxadFRZbk1LTFY5dkV2NzE1TnIzQ3FZMmpvPQ== userCertificate: seeAlso: "ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com Is this all that is needed for verification?
Try using the seeAlso value in a DN e.g. dn: seeAlso="ou=foo,dc=example,dc=com",ou=people,dc=example,dc=com objectClass: top objectclass: extensibleObject seeAlso: <- what happens here?
1 correction... This is not a valid dn syntax: seeAlso: "ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com DN should start with a type like this: seeAlso: cn="ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com Remove uid=scarter,ou=People,dc=example,dc=com Turned on syntaxcheck Add your entry. It fails as follows: adding new entry uid=scarter,ou=People,dc=example,dc=com ldap_add: Invalid syntax ldap_add: additional info: seeAlso: value #0 invalid per syntax This is an expected behaviour. Replace seeAlso: "ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com with seeAlso: cn="ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com Then, add the entry again. It should be added successfully. adding new entry uid=scarter,ou=People,dc=example,dc=com Now, you can run search the entry as follows: 1) using an old DN format $ ldapsearch -b "dc=example,dc=com" '(seeAlso=cn="ou=foo,dc=example,dc=com",ou=bar,ou=example,dc=com)' seeAlso dn: uid=scarter,ou=People,dc=example,dc=com seeAlso: cn=ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom,ou=bar,ou=example,dc=com 2) using a new DN format ldapsearch -b "dc=example,dc=com" '(seeAlso=cn=ou\\=foo\\,dc\\=example\\,dc\\=com,ou=bar,ou=example,dc=com)' seeAlso dn: uid=scarter,ou=People,dc=example,dc=com seeAlso: cn=ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom,ou=bar,ou=example,dc=com 3) using another new DN format $ ldapsearch -b "dc=example,dc=com" '(seeAlso=cn=ou\\3dfoo\\2cdc\\3dexample\\2cdc\\3dcom,ou=bar,ou=example,dc=com)' seeAlso dn: uid=scarter,ou=People,dc=example,dc=com seeAlso: cn=ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom,ou=bar,ou=example,dc=com
(In reply to comment #8) > Try using the seeAlso value in a DN e.g. > dn: seeAlso="ou=foo,dc=example,dc=com",ou=people,dc=example,dc=com > objectClass: top > objectclass: extensibleObject > seeAlso: <- what happens here? $ ldapsearch -b "dc=example,dc=com" '(seeAlso=*)' seeAlsoversion: 1 dn: seeAlso=ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom,ou=people,dc=example,dc=com seeAlso: ou=foo,dc=example,dc=com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jenny, sorry, please ignore my comment 9. It's not related to this bug...
Verified - RHEL 4 version: redhat-ds-base-8.2.0-2010052404.el4dsrv # ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" '(seeAlso=*)' seeAlsoversion: 1 dn: seeAlso=ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom,ou=people,dc=example,dc=com seeAlso: ou=foo,dc=example,dc=com # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope sub # filter: (seeAlso=*) # requesting: seeAlsoversion: 1 dn: seeAlso=ou3Dfoo2Cdc3Dexample2Cdc3Dcom,ou=people,dc=example,dc=com seeAlso: ou=foo,dc=example,dc=com # # ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom, people, example.com dn: seeAlso=ou\3Dfoo\2Cdc\3Dexample\2Cdc\3Dcom,ou=people,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1