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] [Commented] (SSHD-785) ChannelPipedInputStream attempts to read from client even for 0-byte reads.
Date Fri, 17 Nov 2017 11:27:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16256852#comment-16256852
] 

Antti S. Lankila commented on SSHD-785:
---------------------------------------

Sorry for truncation of the comment. I managed to fat-finger the close button. I meant to
just conclude that I'm most realistically going to avoid using SFTP if possible, just because
it's such a complicated protocol for file transfer.

> 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
>             Fix For: 1.7.0
>
>   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)

Mime
View raw message