Adding entries with RDNs enclosed in quotes may lead to entries with illegal DNs

• Key: DIRSERVER-696
• Type: Bug
• Status: Closed
• Resolution: Invalid
• Priority: Major
• Assignee: Emmanuel Lecharny
• Reporter: Stefan Zoerner
• Affects Version/s: 1.0-RC4

Environment

    * ApacheDS 1.0 RC4 SNAPSHOT
    * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
    * Windows XP Professional SP2

Description

Using ApacheDS 1.0 RC4 SNAPSHOT with server.xml unchanged.

If I try to add something like this

dn: ou="Scissors 8<",dc=example,dc=com
ou: "Scissors 8<"
objectclass: organizationalUnit
objectclass: top

an entry is created like that (quotes missing)

dn: ou=Scissors 8<,dc=example,dc=com
ou: Scissors 8<
objectclass: organizationalUnit
objectclass: top

This causes a lot of trouble in some tools I use (LDAP Administrator, for instance). I checked the behaviour of IBM Tivoli Directory Server 6.0 and Sun Java System Directory Server 5.2. They behave different, but both create entries with valid DNs:

Sun:

dn: ou="Scissors 8<",dc=example,dc=com
ou: "Scissors 8<"
ou: Scissors 8<
objectClass: organizationalUnit
objectClass: top

IBM:

dn: ou=Scissors 8\<,dc=example,dc=com
ou: "Scissors 8<"
ou: Scissors 8<
objectclass: organizationalUnit
objectclass: top

I add an LDIF file with this entry and comparable entries, which cause the same error.

Comments

[Stefan Zoerner]

Here is an LDIF file with some example entries which lead to problematic DNs within ApacheDS 1.0 RC4 SNAPSHOT. I used the command line tool ldapmodify to import, and ldapsearch to compare the results.

[Stefan Zoerner]

Here is an addition to the issue. If authorization is enabled before th import, and an ACI is attached to dc=example,dc=com, it is not possible to add the entries at all (this is how I originally found the problem). The authorization subsystem seems to have problems with the illegal DNs, as Softerra LDAP Administrator has after the creation.

Thanks Stefan,

I had time tonite in front of a beer to think again to those issues (this one and DIRSERVER-631). I really think that the LdapDN parser need some improvment. Right now, it's a pile of two versions, and of course it's now really intricated and complicated. Further more, it does not deal with all the cases.

I have drafted a new version on paper, which is :
- simpler
- better
- and likely faster

I hope I will be able to implement it when I will be back, at the end of next week.

[Alex Karasulu]

I'm not going to mess with this one. It's all Emmanuel's :).

[Emmanuel Lecharny]

This is really strange.
creating an entry like :
dn: ou="Scissors 8<",dc=example,dc=com
ou: "Scissors 8<"
objectclass: organizationalUnit
objectclass: top

should throw an exception.
The DN should only contains values that are declared as attributes.
ou="Scissors 8<" attribute is not the same as ou=Scissors 8<.

In DN, the ou="Scissors 8<" RDN correspond to the attribute type and value :
ou = Scissors 8<
where the " are removed.
if you don't create the very same attribute, then you will get an error.
It's weird that IBM and Sun create this attribute (this is the reason why we can see both values in the SUN and IBM results when you do a search).

[Emmanuel Lecharny]

This is definitively not a bug. The " is not part of the value.

[Stefan Zoerner]

You are right Emmanuel. It is an invalid issue. Sorry for the inconvenience. I close this issue.