DO NOT REPLY [Bug 4561] Add options --tweak, --no-tweak, --no-tweak-hlinked

samba-bugs at samba-bugs at
Thu May 8 04:20:06 GMT 2008

------- Comment #6 from matt at  2008-05-07 23:20 CST -------
Note that, as currently implemented, --no-tweak does not prevent tweaking of
non-directories when the destination is subject to malicious concurrent
modification: someone can replace a directory or new file whose attributes
rsync is about to set with a hard link to an existing file.  The following set
of changes would fix this:

1. Use a secure --temp-dir.
2. Use temporary files for all non-directories in the same way as for regular
3. To tweak a directory, open it, fstat the fd to check that it refers to a
directory (i.e., the directory wasn't concurrently replaced), and then set
attributes with f* calls on the fd.

This is secure because all rsync's attribute-setting calls are either in the
temp dir, where a concurrent rsync won't replace files, or on fds that rsync
has verified to refer to directories.  For extra protection, the wrappers for
path-based attribute-setting calls in syscall.c could be enhanced to check that
the path is in the temp dir.

#1 is its own option.  A simple approach to integrating #2 and #3 would be to
simply add them to --no-tweak.  However, #2 is useful even without --no-tweak
to ensure that a destination path always exists while it is being updated. 
Furthermore, --no-tweak is useful without #3 when there is no concurrent
modification but a process that opens a destination file and fstats it twice
must not see the attributes change.  Thus, for maximum flexibility, I propose
making #2 its own option, --stage-all, and adding an option --secure-no-tweak
that includes --no-tweak, --stage-all, #3, and a check that the user specified
a temp dir that appears to be outside the destination (begins with / or ..).

The daemon parameter in bug 5448 would correspond to --secure-no-tweak and
would come with a daemon temp dir that appears to be outside the *module*; of
course, that is only possible when the module path isn't purely a chroot.

Configure bugmail:
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the rsync mailing list