directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <>
Subject Double escaping in DN
Date Wed, 17 Feb 2016 19:53:51 GMT

I have found a rather exotic bug. But it looks like it uncovers quite a 
deep issues in the DN handling.

The DN with escaped chars (such as cn=a\,b,ou=..) is sometimes escaped 
second time (so it becomes cn=a\\\,b,ou=..).

After many failed attempts to replicate the problem in API tests I have 
diagnosed it in the wild. It happens only while communicating with AD. 
And I have found the cause. It goes like this:

The application code makes an ordinary search and gets an entry. The 
entry has DN like cn=a\,b,ou=...
The Dn class parses it, stores it in Rdns which in turn use Ava which in 
turn use Value to store the real values. So it looks like this:

       value (StringValue)
          upValue = cn=a\,b
          normalizedValue = cn=a,b

so far so good.

Now, this is non-schema-aware DN. The application wants a schema-aware 
DN. So it does dn.apply(schemaManager). This code will invoke apply on 
all RDNs which in turn apply it to Avas and Values and finaly the code 
ends up in Dn line 1127. Here is the first bug. This line should be:

atavValue = new StringValue( attributeType, value.getString(), ( ( 
StringValue ) value ).getNormValue() );

because if there is no normValue explicitly provided to the StringValue 
then the constructor assumes that upValue equals normalizedValue which 
is obviously wrong in this case.

But there is another problem. A deeper one. When constructing the value 
the StringValue invokes apply(attributeType) method. This method assumes 
that if there is no equality matching rule then upValue equals 
normalizedValue. Which is wrong.

This bug does not appear in normal case. Schema-less operation skips 
most of the apply(...) methods and the normalized value is not 
overwritten. Full schema-aware code somehow fixes this by normalization 
using the equality matching rule (or some other magic). But the unique 
thing about AD is that it does not define any equality matching rules 
(that is the reason that I was not able to replicate this scenario in 
any tests). So the equality normalization code gets skipped and the 
value gets ruined. It is overwritten by upValue  and the normalized 
value becomes cn=a\,b. Later in the code the normalized value is escaped 
to get the value that is sent over wire. So it becomes cn=a\\\,b. Boom!

What can we do about it?

Is the upValue of cn=a\,b really correct? If it is correct then we 
clearly cannot assume anywhere in the code that upValue equals 
normalizedValue. Honestly, I'm not really sure how to fix this. Any ideas?

Radovan Semancik
Software Architect

View raw message