Bug 504817 - Double quoted distinguished names not working in fedora-ds 1.2.0
Double quoted distinguished names not working in fedora-ds 1.2.0
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.2.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
:
Depends On:
Blocks: 434914 389_1.2.5
  Show dependency treegraph
 
Reported: 2009-06-09 11:32 EDT by tamarinp
Modified: 2015-12-07 11:56 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:56:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed Patch (3.41 KB, patch)
2009-11-11 12:58 EST, Nathan Kinder
rmeggins: review+
nhosoi: review+
Details | Diff

  None (edit)
Description tamarinp 2009-06-09 11:32:29 EDT
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.
Comment 1 Nathan Kinder 2009-11-10 14:33:05 EST
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.
Comment 2 Nathan Kinder 2009-11-10 17:58:50 EST
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.
Comment 3 Nathan Kinder 2009-11-11 12:58:48 EST
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.
Comment 4 Nathan Kinder 2009-11-11 13:58:41 EST
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
Comment 7 Jenny Galipeau 2010-05-17 11:11:59 EDT
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@sasl.net
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@sasl.net
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?
Comment 8 Rich Megginson 2010-05-24 19:17:23 EDT
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?
Comment 9 Noriko Hosoi 2010-05-24 19:20:20 EDT
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
Comment 10 Noriko Hosoi 2010-05-24 19:25:18 EDT
(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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Comment 11 Noriko Hosoi 2010-05-24 19:28:29 EDT
Jenny, sorry, please ignore my comment 9.  It's not related to this bug...
Comment 12 Jenny Galipeau 2010-05-25 16:02:00 EDT
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

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