Hello,
I am investigating a data-loss bug in SSHFS
(https://github.com/libfuse/sshfs/issues/72). While the root cause is in
SSHFS and has already been fixed, there seems to be some unfortunate
interaction with what I believe is an OpenSSH bug:
As far as I can tell, when sending a SSH_FXP_OPEN request with
SSH_FXF_WRITE (i.e., opening the file write only), and then following up
with a SSH_FXP_READ, the server responds with a SSH_FXP_STATUS
indicating that all data has been read.
Shouldn't the server signal some kind of error instead? Or am I making a
mistake in parsing the response?
Thanks,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
?Time flies like an arrow, fruit flies like a Banana.?
Hi, 2017-08-06 11:29 GMT+02:00 Nikolaus Rath <Nikolaus at rath.org>:> Hello, >> > Shouldn't the server signal some kind of error instead? Or am I making a > mistake in parsing the response?I shall test this using my sftp fuse fs with the sftp-server. The translating of posix open flags into sftp flags and access and back on the server is not easy, and if not done as written in the rfc's give this behaviour. Stef
On Aug 06 2017, Stef Bon <stefbon at gmail.com> wrote:> Hi, > > 2017-08-06 11:29 GMT+02:00 Nikolaus Rath <Nikolaus at rath.org>: >> Hello, >> > >> >> Shouldn't the server signal some kind of error instead? Or am I making a >> mistake in parsing the response? > > I shall test this using my sftp fuse fs with the sftp-server.Out of curiosity, how does your sftp fuse fs differ from SSHFS (which also uses FUSE and SFTP)?> The translating of posix open flags into sftp flags and access and > back on the server is not easy, and if not done as written in the > rfc's give this behaviour.Thanks! Looking forward to hear if you can reproduce. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F ?Time flies like an arrow, fruit flies like a Banana.?
2017-08-06 11:29 GMT+02:00 Nikolaus Rath <Nikolaus at rath.org>:> Hello, > > As far as I can tell, when sending a SSH_FXP_OPEN request with > SSH_FXF_WRITE (i.e., opening the file write only), and then following up > with a SSH_FXP_READ, the server responds with a SSH_FXP_STATUS > indicating that all data has been read. >I'm doing the same using my fuse sftp client as described in the sshfs issue 72. The second command echo bar >> test.txt with writeback cache enabled causes also a read command send while the flags send to the sftp server only allow write. The value of pflags indicating how the file has to opened is 6 = 4 | 2 = write and append. This value is used by the sftp server. So far so good. The read command (caused by writeback cache) returns a status reply 2 indicating SSH_FX_NO_SUCH_FILE. (see https://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/draft-ietf-secsh-filexfer-02.txt) This error code is not correct but it's possible that this is the "best guess". The number of error codes in the rfc (which is used by the openssh sftp-server) is very limited. What is the value sshfs receives? In the status codes used by the sftp-server there is no "all data is read". I will test this behaviour with another sftp server. The read command is not there anymore when not using writeback cache. Stef