From owner-freebsd-ports-bugs@FreeBSD.ORG Sat Nov 5 19:20:11 2011 Return-Path: Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C9521065674 for ; Sat, 5 Nov 2011 19:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 395FA8FC0A for ; Sat, 5 Nov 2011 19:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA5JKBbj087082 for ; Sat, 5 Nov 2011 19:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA5JKBOw087081; Sat, 5 Nov 2011 19:20:11 GMT (envelope-from gnats) Resent-Date: Sat, 5 Nov 2011 19:20:11 GMT Resent-Message-Id: <201111051920.pA5JKBOw087081@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ports-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin von Gagern Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E5A1065672 for ; Sat, 5 Nov 2011 19:14:50 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6AE8FC17 for ; Sat, 5 Nov 2011 19:14:50 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pA5JEoos062533 for ; Sat, 5 Nov 2011 19:14:50 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id pA5JEoW4062532; Sat, 5 Nov 2011 19:14:50 GMT (envelope-from nobody) Message-Id: <201111051914.pA5JEoW4062532@red.freebsd.org> Date: Sat, 5 Nov 2011 19:14:50 GMT From: Martin von Gagern To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: ports/162318: rsync data loss outside target dir X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 19:20:11 -0000 >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: