Mailing List Archive

SCP in SFTP mode regression
Hello,

We came across a weird bug using SCP in SFTP mode
Current master, command

./scp -s -S `which ssh` qq localhost:`pwd`/qq

effectively truncates the file to be copied.

SCP mode deals normally.

I understand that it's a corner case but still think it's worth reporting.

Thanks in advance!
--
Dmitry Belyavskiy
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SCP in SFTP mode regression [ In reply to ]
On Tue, 22 Feb 2022, Dmitry Belyavskiy wrote:

> Hello,
>
> We came across a weird bug using SCP in SFTP mode
> Current master, command
>
> ./scp -s -S `which ssh` qq localhost:`pwd`/qq
>
> effectively truncates the file to be copied.
>
> SCP mode deals normally.
>
> I understand that it's a corner case but still think it's worth reporting.

Yes, this is because scp/rcp does open(path, O_CREAT) and then ftruncate()
at close() time, whereas scp/sftp does open(path, O_CREAT|O_TRUNC) on the
basis that in an aborted transfer it's better to leave truncated files
around than files with inconsistent contents.

I don't want to change the behaviour of sftp's upload code, because I think
it is better (at the very least, it allows resumption of transfers without
needing rsync-like tricks), so IMO the best way to avoid this would be to
teach the upload code to go via a temporary file. Not sure whether this is
worth the hassle though for such a corner-case.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SCP in SFTP mode regression [ In reply to ]
On Wed, Feb 23, 2022 at 09:36:00AM +1100, Damien Miller wrote:

> Yes, this is because scp/rcp does open(path, O_CREAT) and then
> ftruncate() at close() time, whereas scp/sftp does open(path,
> O_CREAT|O_TRUNC) on the basis that in an aborted transfer it's better
> to leave truncated files around than files with inconsistent contents.

I see in flags_from_portable() where O_TRUNC is set if SSH2_FXF_TRUNC
is, but I don't think it's set otherwise. It's possible that's always
set somehow though. I haven't looked into how the protocol works enough
to know what's on the queue when sshbuf_get_u32(iqueue, &pflags)) is
called.

I'm assuming here that scp/sftp goes through the code in sftp-server.c.

> I don't want to change the behaviour of sftp's upload code, because I
> think it is better (at the very least, it allows resumption of
> transfers without needing rsync-like tricks), so IMO the best way to
> avoid this would be to teach the upload code to go via a temporary
> file.

My recent patch adds an option to sftp-server.c to force a temporary
file. It would be a trivial change to always do this.

> Not sure whether this is worth the hassle though for such a
> corner-case.

--
nw
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev