Re: DN with semicolon does not work

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:37 PM 5/6/2004, Pierangelo Masarati wrote:

>> I think what we really need to do is to make sure that
>>         DN_SEPARATOR()
>>         NDN_SEPARATOR()
>> are only called with normalized DNs.  Once that is done, then
>> the difference between these macros is moot.
>>
>> I don't think a semi should appear in either a pretty nor a normalized
>> DN.  And if truely an arbitrary DN string, then neither macro is safe to
>> use.
>>
>> Maybe we need to add
>>         assert( (c) != ';' )
>> in a few places to figure out how ';' are getting through to
>> {N}DN_SEPARATOR calls.
>
>I exactly know how they end up there: it is definitely intended; see macro
>LDAP_DN_WILLESCAPE_CHAR() in libraries/libldap/getdn.c.  Escaped semis
>remain as such in both pretty and normalized form because they were
>considered to be harmless if the appropriate DN parsing was to be used.

I'm concerned by the lack of consistency here and how that
impacts administration of slapd(8).   For instance, when
writing regexes to match DNs, one has to know precisely how
the string is normalized.  The inconsistency not only makes
it hard to remember what the normalized form is (as well as
making it harder to document), it makes writing certain kinds
of regexes harder (as the regex has to deal with multiple
escaping mechanisms, instead of one).


>In fact, a normalized/pretty DN will never contain a semi as rdn separator
>(we don't rebuild DNs that way!).  I vaguely recall there was some debate
>at that time, and I was in favour of hexpair escaping ALL the special
>chars in normalized DNs, but someone objected that, besides those that
>have a special meaning in LDAPv3 for DN structure (',', '+', '\'),

I hope it wasn't me who objected.

Anyways, I do think it important that the both pretty and normalized
forms use hex escaping for ALL specials that require escaping (and
no escaping otherwise).  That is, mandatory-to-escape characters
are always hex escaped, non-mandatory-to-escape characters are
always not escaped.

>escaping all would have required to make DNs unnecessarily longer and
>awkward to read (I was in favour of hexpair escaping non-ascii UTF-8 as
>well :)

But that can happen even where there is no escaping changes made.
Consider attribute type name normalization and Unicode normalization.

>My point is that it appears that few DN parsing macros in slap.h
>are not in sync with the corresponding macros used in DN parsing/string
>representation.

Noted.

>Actually, there should be no need to assert (c) != ';', because a ';' in a
>DN, no matter if pretty or normalized, can only be escaped and takes no
>special meaning.

If we move to hex escaping for mandatory-to-escape characters such
as ';', then we could assert (c) != ';' to verify that we've
properly done the normalization/prettying.

>DN_SEPARATOR() really should on test for ',', and
>NDN_SEPARATOR() should not be really used at all.

Yes.