[
https://issues.apache.org/jira/browse/SSHD-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-785 started by Goldstein Lyor.
-------------------------------------------
> ChannelPipedInputStream attempts to read from client even for 0-byte reads.
> ---------------------------------------------------------------------------
>
> 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
> Assignee: Goldstein Lyor
> Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 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 this:
> byte[] buffer = new byte[0];
> in.read(buffer);
> 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
(v6.4.14#64029)
