Mailing List Archive

[Bug 1558] New: Sftp client does not correctly process server response messages after write error
https://bugzilla.mindrot.org/show_bug.cgi?id=1558

Summary: Sftp client does not correctly process server response
messages after write error
Product: Portable OpenSSH
Version: 4.3p2
Platform: amd64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: sftp
AssignedTo: unassigned-bugs@mindrot.org
ReportedBy: simm42@gmail.com


I'm in the process of implementing extensions to sftp-server. One of
these is a maximum file size - if a write attempts to write past the
maximum file size SSH2_FX_PERMISSION_DENIED is returned.

When the client receives this it displays permission denied on screen
and stops the upload.

It then reports ID mismatch and exits.

sftp> put bigfile
Uploading bigfile to /bigfile
bigfile

99% 199MB 6.7MB/s 00:00 ETACouldn't write to remote
file "/bigfile": Permission denied
ID mismatch (6404 != 3)


As can be seen from my server log the permission denied error is
returned to message id 6403

Got message_type SSH2_FXP_WRITE
write id 6403 handle 1 off 209715200 len 32768
ERROR: Attempt to write greater than Max file size, offset: 209715200,
data length:32809



Message id 3 is a close request



Got message_type SSH2_FXP_CLOSE
close id 3 handle 1


However there are several write requests (id 6404 to 6419) that the
client has already sent to the servers input queue - I am assuming
before it has received the error from the server. According to the sftp
spec the server must respond to these packets, however the client
appears to forget about the outstanding messages, performs the file
close and expects the next response message it reads to be a response
to the close, when in fact that message is 16 messages further down the
queue.

The client should correctly handle all status messages for commands it
has issued to the server, even where there has been an error.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs