DnParser does not correctly parse leading and trailing spaces and pound signs in values.

• Key: DIR-184
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Emmanuel Lecharny
• Reporter: Jacob S. Barrett

Description

As defined in RFC 2253 section 2.4:
(http://www.ietf.org/rfc/rfc2253.txt)
..
If the UTF-8 string does not have any of the following characters
   which need escaping, then that string can be used as the string
   representation of the value.

    - a space or "#" character occurring at the beginning of the
        string

    - a space character occurring at the end of the string

    - one of the characters ",", "+", """, "\", "<", ">" or ";"
...

A string can lead with '\ ' and trail with '\ '. Both cases are not supported by the DnParser and cause a parsing error. Furthermore, if a string starts with '\ ' only the spaces leading up to the escape should be trimmed. In addition only the spaces after '\ ' when at the end of a value should be stripped.

looking at the valuelexer.g file '\#' will work anywhere in the string, but should really only be supported at the head of the string.

If I understand the RFC correctly then these string should be supported:
"\ four spaces leading and 3 trailing \ " -> "\ four spaces leading and 3 trailing \ "
" \ two leading three trailing \ " -> "\ two leading three trailing \ "
"\# a leading pound" -> "\# a pound"
"a middle # pound" -> "a middle # pound"
"a trailing pound #" -> "a trailing pound #"

These are not valid:
"middle\ spaces"
"# a leading pound"
"a middle \# pound"
"a trailing pound \#"
Unless the next line in the RFC is really true, "Implementations MAY escape other characters." This makes things a bit more hairy I think.

Comments

[Jacob S. Barrett]

Ignore my comments on the # sign. I am really confused on what the RFC means by leading #. The examples show a string with leading # to define BER octets, but it doesn't escape it, so I am confused.

There is still a problem with leading and trailing spaces.

[Emmanuel Lecharny]

Hi Jacob,

Jira had a problem lately, so it has lost my previous comment ... Hopefully, you added yours, so I wo'nt have to reply to the whole samples ;)

Regarding the spaces, and the 2.4 section, there is something confusing in RFC2253. If you read carefully the section 3, you will see that the gramar tells that there are no way to produce a DN with an attributeValue starting or ending with a '\ '. So this leads to the conclusion that section 2.4 and section 3 are contradictory.

wdyt ?

[Jacob S. Barrett]

I noticed that too, but I am working with names returned by Novell eDirectory and it certainly supports this. I would say the more verbose plain english description is the more "correct". I haven't tested with other directories yet.

[Emmanuel Lecharny]

What we can do is to allow those leading and trailing '\ ', accordingly to the text : "Implementations MAY escape other characters."

A good solution could be to implement this document : http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-ldapbis-dn-06.txt

It's section 2.4 states :
"... Alternatively, if and only if the character to be escaped
  is one of

      ",", "+", """, "\", "<", ">", ";", "#", "=", or " " <----- (has been added to RFC2253)
      (ASCII 44, 43, 34, 92, 60, 62, 59, 35, or 32, respectively)

  it can be prefixed by a backslash ('\' ASCII 92). ..."

So the " " can be escaped.

Could you modify the JIRA report to be an improvment instead of a Major Bug?

[Jacob S. Barrett]

Here is a patch that fixes the spaces problem. It might not be the cleanest solution, but I had to just get something working ASAP.

Basically it keeps track of the non-space (which includes escaped spaces) and spaces separately. If no non-spaces have been parsed it ignores spaces (trims the leading spaces). When done if there are spaces after the last non-space then they are removed (trims trailing spaces).

I am sure there is a cleaner grammer to describe this, but like I said, I don't have the time.

[Emmanuel Lecharny]

This has been fixed and tested.
It will be released in 1.0-RC4.

I reopen the issue because # should *not*ù be escaped in the middle of a DN.

legal values :
dn=\#sharp at the beginning
dn=sharp at the # middle
dn=sharp at the end #

illegal values
dn=#sharp at the beginning
dn=sharp at the \# middle
dn=sharp at the end \#

[Emmanuel Lecharny]

Fixed as it was breaking one of the DIRSERVER-631 tests.