mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antti S. Lankila (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SSHD-785) ChannelPipedInputStream attempts to read from client even for 0-byte reads.
Date Fri, 17 Nov 2017 07:26:00 GMT
Antti S. Lankila created SSHD-785:

             Summary: ChannelPipedInputStream attempts to read from client even for 0-byte
                 Key: SSHD-785
                 URL: https://issues.apache.org/jira/browse/SSHD-785
             Project: MINA SSHD
          Issue Type: Bug
    Affects Versions: 1.6.0
            Reporter: Antti S. Lankila
            Priority: Minor

I ran into interoperability issue between my own implementation of SFTP protocol (don't even
ask) and JSch. The interaction between the client and server hangs on JSch attempting to issue
REALPATH command for the empty string. This is method called getHome(), and it is used to
handle resolving relative paths on the client side. The specifics why it does this are not
important; the bug I ran into affects the situations where any ssh command packet contains
the empty string.

Using the REALPATH "" as example, the data for this command is just 4 zero bytes (length of
string as 32-bit integer), and no string data.

My code attempted to create the 0-byte string based on the length value, and basically executed

    byte[] buffer = new byte[0];

The javadocs for InputStream says that if the length fo the passed byte[] buffer is 0, then
the implementation just returns 0 and doesn't attempt to read anything. Unfortunately, ChannelPipedInputStream
has its own implementation of read(byte[], int, int), and seems to attempt to read something
from client before not actually using the data and returning 0. Client and server deadlock
here: client waits for server reply, server waits for more data from client. Eventually, JSch
timeouts, and closes the connection. What happens is that this 0 byte read then succeeds,
server attempts to write back the FX_NAME response, but client has already closed connection,
and the server gets an exception. In my case, this takes about 8 minutes to happen, which
corresponds to some default timeout in JSch.

The fix would be to detect the attempt to read 0 bytes in ChannelPipedInputStream and just
return early, similar to how java.io.InputStream does read(byte[], int, int). This bug should
be fixed because this would align CPIS's implementation with the documentation and general
behavior of java's InputStreams.

This message was sent by Atlassian JIRA

View raw message