Bug 504817
| Summary: | Double quoted distinguished names not working in fedora-ds 1.2.0 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | tamarinp | ||||
| Component: | Directory Server | Assignee: | Nathan Kinder <nkinder> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 1.2.0 | CC: | jgalipea, nhosoi, nkinder, rmeggins | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-12-07 16:56:28 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 434914, 533025 | ||||||
| Attachments: |
|
||||||
|
Description
tamarinp
2009-06-09 15:32:29 UTC
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 |