Worrisome race condition involving half-transferred files

[Matt McCutchen]

Rsync people,

Tell me if I'm wrong, but rsync seems to have a very serious race
condition that would make it risky to transfer files into a directory
writable by someone you don't trust if permissions are going to be
granted to other people on those files.

The rsync receiver creates a half-transferred file with 600 or 700
permissions; then the receiver writes the data and finalizes the
permissions with "set_perms".

Consider this scenario.  User1 and user2 are both in a group "foo".
"/foo" is the group's shared space; anyone in "foo" can write this
folder.  User1 is using rsync to transfer a file "bar" into this folder;
"bar" is also to be writable by anyone in "foo".  Watch:

user1 rsync receiver: open("/foo/.bar.a1b2c3", O_WRONLY, 0600)
user1 rsync receiver: write a bunch of data to the file descriptor
user2: rm /foo/.bar.a1b2c3
user2: ln ~user1/.bashrc .bar.a1b2c3
user1 rsync receiver: write more data to the file descriptor
user1 rsync receiver: close the file descriptor
user1 rsync receiver: chmod("/foo/.bar.a1b2c3", 660)

Note that at this point the actual "bar" file is gone and user1 has
accidentally changed the permissions of her own "~/.bashrc" file.

user1 rsync receiver: chown("/foo/.bar.a1b2c3", user1, foo)
user2: write into ~user1/.bashrc:
	"echo key-belonging-to-user2 >>~/.ssh/authorized_keys"
user1: start a bash
user2: ssh in and gain user1's privileges

This is bad.  Having the receiver use fchmod, fchown, etc. on the file
descriptor would help.  However, the fact that rsync uses paths from the
top of the transfer for just about everything makes me suspect there
might be other similarly dangerous race conditions.
-- 
Matt McCutchen, ``hashproduct''
hashproduct at verizon.net -- http://mysite.verizon.net/hashproduct/