Delete with illegal DN causes client to hang

• Key: DIRSERVER-634
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Emmanuel Lecharny
• Reporter: Stefan Zoerner
• Affects Version/s: 1.0-RC3

Environment

Sun ONE Directory SDK for Java 4.1
ApacheDS 1.0 RC 3
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Microsoft Windows XP version 5.1 Service Pack 1

Description

A delete operation with an invalid DN causes the client to hang. The expected result is LDAP error code 34 (INVALID_DN_SYNTAX) (preferred), or 32 (NO_SUCH_OBJECT). For instance I tried to delete DN "This is an illegal name,dc=example,dc=com" (no attribute name in RDN).

Unfortunately, I was not able to create this situation with JNDI. Its LDAP Provider seems to ignore such an operation, there is no Exception at all. A Java test case created with Sun ONE Directory SDK for Java caused the client to hang, and does not produce the result code expected. I'll attach it to this issue.

Comments

[Stefan Zoerner]

This is the JUnit test case using Sun ONE Directory SDK for Java 4.1 or comparable (Netscape, Mozilla).

[Emmanuel Lecharny]

As far I I can have test this issue, I can't reproduce it. What I can just say is that the deletion of a bad DN generates the correct LdapResult (NO_SUCH_OBJECT) on the server, and this is such a result which is transmitted to the client.

The problem is that the sun JNDI client implementation does not catch any exception, whichever method I used to delete the bad entry (unbind() and destroySubContect())

I mark it as "Won't fix" unless we can reproduce this problem with a JNDI test case. (it may perfectly be a problem with the client API used. May be an analyse of the underlying data sent end received could help to figure out what exactly happens).

[Stefan Zoerner]

Yes, I was not able to create the situation with JNDI due to the strange error handling the API has.

Please note, that the attached test case DeletionWithIllegalNameTest.java passes with the following products

  * Sun Java System Directory Server 5.2
  * IBM Tivoli Directory Server 6.0
  * OpenLDAP 2.3

and fails with ApacheDS 1.0 RC3. So I do not think it is a client API problem.

One alternative to create a comparable situation is to execute the LDIF file I attach:

$ ldapmodify -D "uid=admin,ou=system" -w ****** -f DIRSERVER-634.ldif

It causes a protocol error on Apache DS (log file is attached as well), which I assume is the origin of the original error described in this issue.

[Stefan Zoerner]

LDIF to demonstrate DIRSERVER-634

[Stefan Zoerner]

A logfile for DIRSERVER-634

[Emmanuel Lecharny]

It seems that the problem is really somwhere around Apache DS ...

[Emmanuel Lecharny]

Ok, this is my fault.

The ASN.1 BER decoder analyze the DN and try to parse the DN. If it does fail, the it throw a DecoderException, which leads to a protocol error.

This is really bad, and this will happen almost everywhere we have a DN in a request. An INVALID_DN_SYNTAX must be thrown instead.

[Alex Karasulu]

Looks like Emmanuel want's this issue more than me. :)

[Emmanuel Lecharny]

Well, it's not so clear. Here is a status :

1) bytes arrive from the client.
2) ASN.1 codec is called
3) The request is analyzed by TwixDecoder
4) If there is a DN, it is parsed
 4-1) If the DN is wrong, then a DecoderException is generated, so the client receive a Protocol Error instead of a LdapResult
 4-2) Else, we pass the request to TwixTransformer
5) TwixTransformer transform a TwixRequest to a SnickersMessage
 and here is tyhe problem : SnickersMessage hold a LdapDN, too. So we can't wait until we reach the Handler to check that the DN is correct or not.

Rrrrrrahhhhhh !!!! We have to find a solution which does not implies that we don't rewrite *all* the snickezrs and twix messages ...

[Emmanuel Lecharny]

Fixed ! A common work with Alex finally terminated this issue. The bad DN thew an exception, which was not catched. Now, when we get a excpetion while parsing this DN, we generate a DelResponse where the LdapResult contains the error code.

This should be done for every places where the DN is parsed

[Stefan Zoerner]

I have checked the situation (test case with delete) with a fresh build from the 1.0 branch of Apache DS. It works perfect. Thanks for fixing it Emmanuel, I close this issue.

One more information : while playing with JUnit4, I was slapped in the face by this issue again. The pb is that there is a bad bug in JNDI when calling a destroySubcontext() with an already deleted entry : JNDI modify the resultCode from NO_SUCH_OBJECT to LDAP_SUCCESS simply because it consider that, as soon as the base DN is Ok, and only the RDN does not exist, then it must be a success !!!

As is, deleting "cn=This does not exist, dc=example, dc=org" will return a NO_SUCH_OBJECT LdapResult, with a matchedDN = "dc=example, dc=org", and JNDI will consider that as there is only one level between the baseDN and the deleted entry DN, then it's a success.

Thanks JNDI !!!