ports/162318: rsync data loss outside target dir

[Martin von Gagern]

>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 at 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: