You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Mark Riordan <mr...@ipswitch.com> on 2014/07/16 17:41:54 UTC

Read-only SSH_FXP_OPEN returns success even if file doesn't exist

I've encountered what I think is a bug in the Apache SSH server.  Before I submit a patch, I'd like to run this by the list in case I'm missing something.


In short, read-only file opens succeed even if the file does not exist.  The subsequent file read commands are doomed to failure.


In greater detail:

SftpSubsystem.process() has a switch statement that processes commands.  File open processing is done by the SSH_FXP_OPEN case.  The code here succeeds even if file.doesExist() is false and the SSH_FXF_CREAT bit isn't set.  As a result, a handle is returned to the client as if everything were OK.  But when the client tries to do a SSH_FXP_READ on that handle, there will be no file that's actually open.  In this case, my application not unreasonably returns an error.


The problem is that this works poorly with some clients - most notably the widely-used PSFTP.EXE.  What happens is that the client, seeing that the open succeeded, issues a large number of initial read requests, in order to optimize the flow of packets.  However, every one of these read requests fails.  And in my case, each results in a error record being logged in the application.  For PSFTP, that's 32 errors logged for each open of a non-existing file. For most other clients, the problem doesn't occur because they explicitly check for the existence of a file before trying to open it. However, PSFTP's behavior is perfectly reasonable.


It seems to me that SftpSubsystem.process() should return an error if the file doesn't exist and the caller doesn't want to create the file.


Any reason I shouldn't submit a patch?


Thanks.


Mark R


I apologize that I erroneously submitted a similar question to the users mailing list, before I realized there was a separate list for developers.



Re: Read-only SSH_FXP_OPEN returns success even if file doesn't exist

Posted by Guillaume Nodet <gn...@apache.org>.
I agree this looks like a bug.
Feel free to raise a JIRA and attach a patch !


2014-07-16 17:41 GMT+02:00 Mark Riordan <mr...@ipswitch.com>:

> I've encountered what I think is a bug in the Apache SSH server.  Before I
> submit a patch, I'd like to run this by the list in case I'm missing
> something.
>
>
> In short, read-only file opens succeed even if the file does not exist.
>  The subsequent file read commands are doomed to failure.
>
>
> In greater detail:
>
> SftpSubsystem.process() has a switch statement that processes commands.
>  File open processing is done by the SSH_FXP_OPEN case.  The code here
> succeeds even if file.doesExist() is false and the SSH_FXF_CREAT bit isn't
> set.  As a result, a handle is returned to the client as if everything were
> OK.  But when the client tries to do a SSH_FXP_READ on that handle, there
> will be no file that's actually open.  In this case, my application not
> unreasonably returns an error.
>
>
> The problem is that this works poorly with some clients - most notably the
> widely-used PSFTP.EXE.  What happens is that the client, seeing that the
> open succeeded, issues a large number of initial read requests, in order to
> optimize the flow of packets.  However, every one of these read requests
> fails.  And in my case, each results in a error record being logged in the
> application.  For PSFTP, that's 32 errors logged for each open of a
> non-existing file. For most other clients, the problem doesn't occur
> because they explicitly check for the existence of a file before trying to
> open it. However, PSFTP's behavior is perfectly reasonable.
>
>
> It seems to me that SftpSubsystem.process() should return an error if the
> file doesn't exist and the caller doesn't want to create the file.
>
>
> Any reason I shouldn't submit a patch?
>
>
> Thanks.
>
>
> Mark R
>
>
> I apologize that I erroneously submitted a similar question to the users
> mailing list, before I realized there was a separate list for developers.
>
>
>