Date: Sat, 5 Nov 2011 19:14:50 GMT From: Martin von Gagern <Martin.vGagern@gmx.net> To: freebsd-gnats-submit@FreeBSD.org Subject: ports/162318: rsync data loss outside target dir Message-ID: <201111051914.pA5JEoW4062532@red.freebsd.org> Resent-Message-ID: <201111051920.pA5JKBOw087081@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 162318
>Category: ports
>Synopsis: rsync data loss outside target dir
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Nov 05 19:20:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Martin von Gagern
>Release: 9.0-RC1
>Organization:
>Environment:
FreeBSD gringotts.fritz.box 9.0-RC1 FreeBSD 9.0-RC1 #0: Tue Oct 18 18:51:43 UTC 2011 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
Lots of details up front, most relevant facts in the next paragraph. I've set up a zfs-based FreeBSD for backup purposes, based on rsync. The sending side is a Gentoo Linux machine. While sending pretty much my my whole file system content, the sending side crashed. I rebooted, and restarted rsync. After all, it's supposed to handle existing content, right? rsync proceeded, printed some error messages which got lost among the output generated by --progress. Something about missing permissions for xattrs. Only noticed them by accident. Then some transfer got stalled, and I interrupted rsync on the sending side using Ctrl+C. I tried to resume rsync, and was suddenly asked to enter my password, although I had set up login using an ssh public key.
Logging into the receiving FreeBSD as root, I found that large parts of the user's home directory content had disappeared!
- All the .* config files in the home directory were gone
- The .ssh directory was still present, but its content was gone as well
- Both the home dir and the .ssh subdir contained a file "rsync.%stat"
- The backup directory used as a target was still present, and had at least
some content. As it was never complete, I don't know if things were missing.
This looks like two problems to me, but as they might well be connected, I'm filing a single report for both of them.
1. rsync should never touch anything outside its target directory.
2. "rsync.%stat" should be the name a user extattr (aka. xattr), not a file
I'll list the complete set of command line arguments below, but I believe the following are most likely triggers for the above problems:
1. "--relative" together with a source argument of "/" might have confused rsync enough to make it believe that should operate outside the named target directory. "--delete" would have encouraged it to also remove stuff. Perhaps the stalled operation was due to rsync trying to remove all the data transferred in the first run?
2. "--rsync-path='rsync --fake-super'" is certainly the cause for xattr-related code and any function call receiving "rsync.%stat" as an argument. How that ended up as a file name is still a mystery to me, though. I've installed almost all of my system from binary packages. Could it be that some library changed its ABI without a change in SONAME version number? That's the most likely cause I can imagine for function arguments having an unintended meaning.
>How-To-Repeat:
I didn't exactly reproduce this, as I don't fancy loosing any more data than I already have. But the original command was pretty much the following:
rsync --relative --rsync-path='rsync --fake-super' \
--archive --hard-links --acls --xattrs --sparse \
--delete --delete-delay --fuzzy --human-readable --progress \
-f 'S somestuff' -f 'H otherstuff' -f 'H /dev' -f 'H /proc' \
/ freebsdmachine:~/backup/
The -f rules were actually more numerous, but you get the idea.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111051914.pA5JEoW4062532>