Issue Details (XML | Word | Printable)

Key: DIRSERVER-383
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Stefan Zoerner
Reporter: Endi S. Dewata
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Directory ApacheDS

ldapmodrdn failed upon encountering blank space

Created: 12/Nov/05 04:52 AM   Updated: 04/Oct/06 04:54 PM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Resolution Date: 06/Dec/05 07:42 AM


 Description  « Hide
When specifying multiple entries for ldapmodrdn operation, according to the manual page (http://linuxcommand.org/man_pages/ldapmodrdn1.html) "one or more blank lines may be used to separate each DN/RDN pair." However, it seems that currently ApacheDS does not allow any blank lines in the ldapmodrdn input.

Note: I'm not sure if at least one blank line is actually required to separate the entires. To be safe, the blank line maybe can be made totally optional.

The following operation currently will succeed in renaming both entries.

> ldapmodrdn -h localhost -p 10389 -D uid=admin,ou=system -w secret -r
ou=test,dc=apache,dc=org
ou=test2
ou=test2,dc=apache,dc=org
ou=test

The following command currently will fail on the second entry:

> ldapmodrdn -h localhost -p 10389 -D uid=admin,ou=system -w secret -r
ou=test,dc=apache,dc=org
ou=test2

ou=test2,dc=apache,dc=org
ou=test

Here is the exception:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
        at java.util.ArrayList.RangeCheck(ArrayList.java:507)
        at java.util.ArrayList.remove(ArrayList.java:392)
        at org.apache.ldap.common.name.LdapName.remove(LdapName.java:605)
        at org.apache.ldap.server.protocol.ModifyDnHandler.messageReceived(ModifyDnHandler.java:79)
        at org.apache.mina.protocol.handler.DemuxingProtocolHandler.messageReceived(DemuxingProtocolHandler.java:70)
        at org.apache.mina.protocol.AbstractProtocolFilterChain$2.messageReceived(AbstractProtocolFilterChain.java:149)
        at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
        at org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(AbstractProtocolFilterChain.java:50)
        at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524)
        at org.apache.mina.protocol.AbstractProtocolFilterChain$1.messageReceived(AbstractProtocolFilterChain.java:99)
        at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
        at org.apache.mina.protocol.AbstractProtocolFilterChain.messageReceived(AbstractProtocolFilterChain.java:356)
        at org.apache.mina.protocol.ProtocolSessionManagerFilterChain$1.messageReceived(ProtocolSessionManagerFilterChain.java:77)
        at org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
        at org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(AbstractProtocolFilterChain.java:50)
        at org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524)
        at org.apache.mina.protocol.filter.ProtocolThreadPoolFilter.processEvent(ProtocolThreadPoolFilter.java:108)
        at org.apache.mina.util.BaseThreadPool$Worker.processEvents(BaseThreadPool.java:393)
        at org.apache.mina.util.BaseThreadPool$Worker.run(BaseThreadPool.java:333)

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Stefan Zoerner made changes - 14/Nov/05 05:59 AM
Field Original Value New Value
Comment [ Now I have finally understood.

I do not understand this manual thing "One or more blank lines may be used to separate each DN/RDN pair". Not that you have to use the OpenLDAP client here, because others (Solaris9, Tivoli to name two) won't let you enter blank lines ... If I do the following:

$ ldapmodrdn -h <hostname> -p <port> -x -D <bindDN> -w <passwd> -r

and start to enter my parameters interactively, the client sends a modify DN request after each two lines:

(1) ou=A,dc=bundestag,dc=de
(2) ou=B => Request (works)
(3)
(4) ou=B,dc=bundestag,dc=de => Request

The second request leads to various errors, here two examples:

Sun Java System Directory Server 5.2:
Rename Result: Protocol error (2)
Additional info: null original dn

OpenLDAP 2.1
Rename Result: Server is unwilling to perform (53)
Additional info: cannot rename the root DSE

Therefore this tool does not seem to me to allow you to separate parameter pairs by blank lines.

---

Our fault: We do not send the correct error here. The input with blank line leads to a request with req.getName() empty and later to a RuntimeExcpetion in class org.apache.ldap.server.protocol.support.ModifyDnHandler, as displayed in stack trace provided by Endi.

We should decide/find out which error to throw in that situation, and throw it. Currently, the client does not get an error at all, and therefore does not take notice of the problem occurred. ]
Stefan Zoerner made changes - 14/Nov/05 05:59 AM
Comment [ I tried to reproduce this one, and was able to.
It occurred with the client tools provided by OpenLDAP, but not with the command line tools provided by Solaris9 and IBM Tivoli Directory Server 6.0.
I am still trying to understand, what the OpenLDAP client does, if blank lines are provided.
Btw.: the other tools behave totally different. ]
Stefan Zoerner added a comment - 14/Nov/05 06:00 AM
I do not understand this manual thing "One or more blank lines may be used to separate each DN/RDN pair". Note that you have to use the OpenLDAP client here to see the effect described in the issue, because others (Solaris9, IBM Tivoli DS to name two) won't let you enter blank lines ... If I do the following:

$ ldapmodrdn -h <hostname> -p <port> -x -D <bindDN> -w <passwd> -r

and start to enter my parameters interactively, the client sends a modify DN request after each two lines:

(1) ou=A,dc=bundestag,dc=de
(2) ou=B => Request (works)
(3)
(4) ou=B,dc=bundestag,dc=de => Request

The second request leads to various errors, here two examples:

Sun Java System Directory Server 5.2:
Rename Result: Protocol error (2)
Additional info: null original dn

OpenLDAP 2.1
Rename Result: Server is unwilling to perform (53)
Additional info: cannot rename the root DSE

Therefore this tool does not seem to me to allow you to separate parameter pairs by blank lines.

---

Our fault: We do not send the correct error here. The input with blank line leads to a request with req.getName() empty and later to a RuntimeExcpetion in class org.apache.ldap.server.protocol.support.ModifyDnHandler, as displayed in stack trace provided by Endi.

We should decide/find out which error to throw in that situation, and throw it. Currently, the client does not get an error at all, and therefore does not take notice of the problem occurred.

Stefan Zoerner made changes - 04/Dec/05 09:36 PM
Assignee Alex Karasulu [ akarasulu ] Stefan Zoerner [ szoerner ]
Repository Revision Date User Message
ASF #354207 Mon Dec 05 22:20:52 UTC 2005 szoerner Add a test for empty names in order to prevent clients to rename Root DSE. This is due to DIREVE-307.
Files Changed
MODIFY /directory/protocol-providers/ldap/trunk/src/main/java/org/apache/ldap/server/protocol/support/ModifyDnHandler.java

Stefan Zoerner made changes - 06/Dec/05 01:51 AM
Status Open [ 1 ] In Progress [ 3 ]
Stefan Zoerner added a comment - 06/Dec/05 07:35 AM
I have modified class ModifyDnHandler -- it now sends a protocol error, if a client tries to modify the DN of Root DSE. This is error code (2) which Sun Java System Directory Server (and others) send, although I have not find a clear definition within RFC 2251, which error code is the right one.

http://svn.apache.org/viewcvs.cgi?rev=354207&view=rev

Stefan Zoerner added a comment - 06/Dec/05 07:42 AM
From my point of view (see comments in the JIRA issue) this is fixed with

http://svn.apache.org/viewcvs.cgi?rev=354207&view=rev

Stefan Zoerner made changes - 06/Dec/05 07:42 AM
Resolution Fixed [ 1 ]
Status In Progress [ 3 ] Resolved [ 5 ]
Alex Karasulu made changes - 10/Feb/06 12:34 PM
Key DIREVE-307 DIRSERVER-383
Component/s protocol [ 11087 ]
Project Directory Server [ 10516 ] Directory ApacheDS [ 12310260 ]
Affects Version/s 0.9.3 [ 12310193 ]
Endi S. Dewata made changes - 04/Oct/06 04:54 PM
Status Resolved [ 5 ] Closed [ 6 ]