DO NOT REPLY [Bug 3718] RSync should verify permission/time before commiting a change

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=3718





------- Comment #3 from hashproduct at verizon.net  2006-04-24 16:13 MST -------
(In reply to comment #0)
> I checked the code, and noticed that before "rsync" commit the temp file 
> (finish_transfer @ rsync.c), it changes the file attributes (using
> 'set_file_Attrs'). However, it does not check if the file attributes were
> updated succesfully. As a result, it may leave files with the wrong
> timestamp/ownership or permission.

Why isn't your operating system letting rsync set the file attributes? 
Obviously, if you move (or delete) a file out from under rsync's nose, there's
little that rsync can do about it.  However, if rsync is spuriously failing to
set attributes, I recommend you truss it to find the cause.  If you are
pulling, do something like this:
    truss -dfo rsync.log rsync there:files/ files/
If you are pushing, do something like this and then download the log file from
the other machine:
    rsync --rsync-path="truss -dfo rsync.log rsync" files/ there:files/

That said, I do believe rsync 3 needs to be a savvier reader and writer of the
filesystem instead of complacently doing what would work assuming no concurrent
modification.  Perhaps as an option, rsync 3 should perform additional
"defensive" checks to make sure that each received file matches the file list,
at least in preserved attributes.  In addition, as much as possible on its
system, it should use file descriptors and f* and *at system calls in place of
following paths from the root of the transfer.  Since file descriptors are
foolproof, this would greatly reduce race conditions, including those dangerous
to security.  Unfortunately, there are some deficiencies in this technique:

(1) One must open a file for reading or writing, not just to have a file
descriptor for f* calls.

(2) One can't open symlinks.  A "lopen" call that opens a file and/or symlink
for neither reading nor writing would fix both #1 and #2.

(3) One can't read directories atomically.  An "openall" call that atomically
lopens all the files in a directory and returns a list of their names and file
descriptors would fix this, but the memory allocation would be tricky and we
have to hope for a high file descriptor limit.  Furthermore, if a file is moved
while rsync is working, rsync might see it twice or never; I see no way to
prevent this.

I'm doing some kernel hacking, and I'm thinking about making a customized Linux
kernel with the necessary system calls to allow programs like rsync to operate
safely in the face of concurrent modification.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.