openssh bugs - Jan 2004 - [Bug 794] scp2 copy from machine A (openssh 3.5p1) to B (ssh 2.4.0) causes transferred file to be empty

http://bugzilla.mindrot.org/show_bug.cgi?id=794

           Summary: scp2 copy from machine A (openssh 3.5p1) to B (ssh
                    2.4.0) causes transferred file to be empty
           Product: Portable OpenSSH
           Version: -current
          Platform: ix86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: scp
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: storri at torri.org


I have two computers, A and B for this discussion, which run two different
versions of ssh. Computer A runs OpenSSH 3.5p1 (RedHat 9) and computer B runs
(ssh 2.4.0 non-commercial version). The home directory for my user is handled by
NFS. So my home directory is mounted via NFS to both A and B. So why am I
bothering to use scp? I did not know these machines were connected via NFS. Yet
there was a interesting bug in scp2 discovering in attempting the copy.

So the file exists before the transfer:

-bash-2.05b$ ls -l cs507.ps
-rw-r--r--    1 storri   student    169557 Jan 23 16:32 cs507.ps

So I do the transfer with scp2 from home directory on A to home directory on B:

-bash-2.05b$ scp2 cs507.ps twist:
storri at twist's password:
cs507.ps                                                                      |
    0B |   0.0 kB/s | ETA: 1+23:05 |   0%
-bash-2.05b$

So ok its a bit worrying that nothing was supposedly transfer. So what happened?
 Here is the status of the original file after running this command:

-bash-2.05b$ ls -l cs507.ps
-rw-r--r--    1 storri   student         0 Jan 23 16:39 cs507.ps

Here is the bug. When the transfer fail, which it should not, the original file
is empty. Now that is really wrong. When setting up the destination to receive
the file scp truncates the destination file to zero lenght. However since the
destination file is the same as the source file then it also truncating the
source file. Therefore it destroys the data.

Machine A ssh version: OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
Machine B ssh version: ssh: SSH Secure Shell 2.4.0 (non-commercial version) on
i686-pc-linux-gnu

I did a copy via scp2 from a openssh 3.5p1 box to another openssh 3.5p1 box
where source and destination directory where the same connect via NFS. It also
destroyed the contents of the file as described above.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=794

mouring at eviladmin.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From mouring at eviladmin.org  2004-01-23 15:51
-------
There is no way to for sftp subsystem or scp to know that they are the same 
file.

Try it with ftp, rcp, etc and you'll find the same behavior.

- Ben



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=794





------- Additional Comments From dtucker at zip.com.au  2004-01-23 16:14 -------
(Ben beat me to the update, but I thought I'd add my 2 cents anyway).

Although it's nasty it's doing exactly what you told it to.  The steps
scp will
take are (in approximate order):
1) open source file for read
2) connect to target system
3) truncate destination file
4) send source file
5) write destination file

Because your source and destination are the same, it goes pear-shaped at point
3.

I'm not sure what scp could do about it.  If it used a temp file or unlinked
the
destination first, because scp is unprivileged there's no guarantee that
file
permissions, ownership or non-traditional filesystem metadata (like ACLs), could
be restored (currently they'll remain unchanged).

Perhaps the only advice I can offer is "don't do that" (or
possibly "use rsync
for that" since it will use temp files).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.