openssh unix dev - Jan 2003 - ownership permissions on files replaced via scp -- bug or feature?

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?
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.

Suppose we have 2 files on different hosts, with different group
ownership and permissions. user1 is not a member of either group foo or
group bar:

user at host1:/tmp% ls -l /tmp/testfile
-rw-r--r--    1 user1  foo         5 Jan  6 11:14 /tmp/testfile

user at host2:~% ls -l /tmp/testfile
-rw-rw-r--    1 user1  bar         6 Jan  6 11:37 /tmp/testfile

If I then scp this file from host1 to host2: 

laytonj at host1:/tmp% scp testfile host2:/tmp

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.

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.

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.

-- 
Jeffrey Layton <Jeff.Layton at bellhowell.com>
Bell & Howell MMT
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030106/4b29e38c/attachment.bin

ihmo, the ownership of the target file should only be changed
if -p is given on the command line.

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

Got it -- that does make sense. Thanks for help from all on the list!
-- 
Jeff Layton <jeff.layton at bellhowell.com>