[Date Prev][Date Next]
RE: Error searching DNs with escaped special characters
> Okay, after taking another look at slapd log (started as you suggested
> with -d -1), I've figured out the subtleties of how to construct my DNs
> in the back-sql ldap_entries table so that searches on escaped special
> characters work.
> However, I have observed two inconsistencies in behavior. One may be
> desired, but the other might need to be addressed. (recall I'm using
> 2.1.16 with back-sql off of MS SQL Server 2000)
> Inconsistency 1:
> Special characters ",", "+", and "\" require that their ASCII hex code
> be inserted in the ldap_entries DN string following the escape character
> (\). Special characters """, "<", ">", ";" require the actual
> character. Furthermore, search results display in the same manner
> (regardless of client); that is, the first set of characters display
> with hex code, the second set with actual character. This seems a bit
> inconsistent in that it makes the underlying construction of the DN in
> the directory database less transparent --though maybe it's desired
> and/or necessary for interoperability -?
> Note that both sets of characters (with one exception, see below) allow
> the search to be issued by escaping either the ASCII hex value or the
> actual character --good from the client standpoint.
> (succeeds) ldapsearch -b "cn=CITY\2B
> (succeeds) ldapsearch -b "cn=CITY\+
This should not be targeted as an inconsistency,
but rather a design choice; in fact, we decided
to always escape as hexpair those special chars
that have a special meaning in a DN, so that things
like subtree match and regular expressions in ACLs
and more do not require any special handling.
Note that this is allowed by rfc2253, which states
that implementations may want to sescape other
chars and states that \<special char> and \<hexpair>
are the same. Note again that in internal
representations, AVA values in DNs do not have any
char escaped; they get escaped as soon as their
string representation as a DN is needed, e.g. in
logs; that's why you'll never see a "," escaped
as \, in a log, regardless of how you crafted your
> Inconsistency 2:
> An escaped backlash character, "\", can only be searched for by
> specifying the ASCII hex code when double quotes delimit the DN. If
> single quotes delimit the DN, then it can also be searched by specifying
> "\\". This may not seem like a big deal, except that it causes searches
> to fail in other LDAP clients, like the Jarek Gawor JAVA browser.
> (succeeds) ldapsearch -b "cn=CITY\5C
> (fails) ldapsearch -b "cn=CITY\\
> (succeeds) ldapsearch -b 'cn=CITY\\
> For what it's worth, I've appended a table summarizing the tests I
This case looks like a shell escape is taking precedence
over slapd's interpretation. I don't see why case (2)
should be different from case (3) in the above example.
Check out what shell you're using, and what's its escape
and quoting policy.
> Thanks as always,
> Ken Turley
> spcl ldap_entries search search client
> wildcard char DN contains: for: y/n for: y/n displays
> displays ---- ------------- ------ --- ------ ---
> -------- --------
> , \2C \2C Y \, Y \2C \2C
> , \, \2C N \, N - \2C
> + \2B \2B Y \+ Y \2B \2B
> + \+ \2B N \+ N - \2B
> \ \5C \5C Y \\ N,Y (*) \5C \5C
> \ \\ \5C N \\ N - \5C
> > \3E \3E N \> N - \>
> \> \3E Y \> Y \> \>
> < \3C \3C N \< N - \< <
> \< \3C Y \< Y \< \<
> ; \3B \3B N \; N - \; ;
> \; \3B Y \; Y \; \;
> " \22 \22 N \" N - \" "
> \" (**) \22 Y \" Y \" \"
> (*) - Failure here where others succeed if double quotes (") delimit
> the DN, but succeeds if single quotes (') delimit the DN
> (**) - DN must be delimited on ldapsearch command line with single quote
> marks (') instead of double (").
>> -----Original Message-----
>> From: Pierangelo Masarati [mailto:email@example.com]
>> Sent: Monday, July 21, 2003 12:58 PM
>> To: Ken Turley
>> Cc: openldap-software@OpenLDAP.org
>> Subject: RE: Error searching DNs with escaped special characters
>> > And is Nikita's problem related to the one I described with my post
>> originally under this subject heading on 7/17/2003? (text of posting
>> attached) Thanks, K. Turley.
>> Actually, I don't see the problem; everything seems to work fine with
>> respect to DN escaping chars, and significantly with \,
>> escaping; maybe
>> you're exploiting some problem with back-sql. You might want to look
>> at how the DN is parsed by checking slapd's log (with -d -1) and, in
>> case everything looks good, check how the client is parsing the DN.
>> Pierangelo Masarati