ownership permissions on files replaced via scp -- bug or feature?

[Bob Proulx]

Jeffrey Layton <Jeff.Layton at bellhowell.com> [2003-01-06 11:52:57 -0500]:
> I've noticed the following behavior on files that are overwritten with
> an scp command and I can't decide if this is intended behavior or a bug?

I am sure the original UNIX behavior evolved as a natural consequence
of the filesystem model.  It was the default behavior of cp when the
target file is a previously existing file.  Now after 30 years of
usage, it certainly is the expected behavior for cp.

Since scp is modeled after cp it follows that scp should behave
similarly to cp.  It does not have to follow it exactly.  But in the
cases that it does not there should be good reason to depart from
accepted practice.

> Can someone with a little more insight please share the reasoning for
> this (if any)? I've tested this with a mix of 3.4p1 and 3.5p1 hosts.

You might want to look at the behavior of 'cp' in this regard.  Or
'cat src > dst' for that matter.  You will find them to be the same.
This is not something new and unique to scp but common program behavior.

> The contents of testfile on host2 are overwritten, but permissions and
> ownership are preserved.
> 
> user at host2:~% ls -l /tmp/testfile
> -rw-rw-r--    1 user1  bar         5 Jan  6 11:39 /tmp/testfile
> 
> The same rule applies as long as the user has write permission to the
> file. sshd seems to preserve permissions on any file that is replaced,
> whether the user making the copy is a member of that group or not.

You used the word 'overwrite' most of the time in the message.  But
then here you say 'replaced'.  Saying overwrite is more accurate since
the file is previously existing it is getting overwritten with new
file contents.  The inode and therefore the owner, group, mode, is not
changing.

> It seems to me that the permissions should be set as if the user were
> creating a new file here unless for instance, the -p flag is used, and
> the user is capable of setting permissions on the resulting file to
> match the source file.

If this bothers you then you could always use 'rsync -e ssh' which
behaves this way only because it always creates a temporary file on
the side and then moves the new file into place instead of overwriting
existing files.

> Is this also potentially a security hole? A malicious user with the
> ability to write to a file might be able to upload a trojaned binary
> here or some such mischief.

I can tell you are excited but there is no security hole here.  I am
also sure many people count on setting the permission on a file in a
specific configuration and then updating the file with scp without it
changing the owner, group, mode of the file from the previous value.
If that were to change then many people's scripts and programs would
be broken without good reason.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030107/d5177880/attachment.bin