Worrisome race condition involving half-transferred files

[Matt McCutchen]

On Fri, 2005-10-14 at 14:33 -0700, Wayne Davison wrote:
> This is not something that is unique to rsync.  For instance, if I
> hard-link a file in that dir to a file that is owned by root, and root
> uses "cp" to update that file, the hard-linked, root-owned file will be
> affected.

True.  Incidentally, this is why I rejoiced when my school's Linux
server (binx.mbhs.edu) got ACL support.  For some time, we had been
running automatic permission resetters as root on certain folders (very
dangerous); now, we're using default ACLs.

> One way to avoid a race like the one your cited is to use the --temp-dir
> option: as long as your --temp-dir is on the same partition as the
> destination dir and is only writable by you, you can avoid the
> permission-changing problem you cited.

Thanks for pointing that out.  I can create such spaces on my own
system, but, alas, they might not be present on every system.

Here's a cooler technique: Have the receiving rsync create a single
temporary directory inside the destination with mkdtemp or similar and
keep a file descriptor (say #77) open on the directory.  Then it can
pretend that /proc/self/fd/77 was specified as the temporary directory.
This will involve hardly any changes to rsync, and I don't see any
obvious security problems with it.  Perhaps I'll write a patch for this
and incorporate it into my customized rsync, maybe even as the default.

> It might be worthwhile to also look into modifying rsync to use fchmod()
> when possible, but in reality, if you're updating files in a directory
> where you don't trust the users, there are lots of ways for them to
> cause you trouble.

Altogether too true.  The risk of attack is most obvious for
long-running automated programs like rsync, but if I so much as edit a
file in a project shared space, I might actually be editing my
~/.bashrc...discomforting thought.  To deal with this, Linux filesystems
need restrictions on hard-linking and some kind of optimistic locking.
-- 
Matt McCutchen, ``hashproduct''
hashproduct at verizon.net -- http://mysite.verizon.net/hashproduct/