Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
1.6.0
-
None
Description
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.
