This is a discussion on Re: Worrisome race condition involving half-transferred files - Tools ; 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 ...
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
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''
email@example.com -- http://mysite.verizon.net/hashproduct/
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html