On Sat, 2008-08-02 at 09:41 -0500, Neil Gunton wrote: > Thanks for the tip. I just took at look at the man page for rsyncd.conf > and it seems to warn you away from combining chroot: > > "... disadvantages of ... complicating the preservation of users and > groups by name (see below)."
The "disadvantages" are that (1) rsync uses the /etc/passwd inside the chroot instead of the global one and (2) there are security issues when exposing a writable daemon to untrusted users. But (1) is precisely what you want and (2) doesn't apply, so you can ignore the warning. > I'm suggesting that it might be a nice addition to rsync if we could add > an option to use a passwd file for the mapping of the src uids to the > current (dest) uid/username system. This would then mean you don't have > to set up a special chrooted rsync daemon simply in order to do restore > from your local backup drive. Instead you could just do something like: > > rsync -av --src-passwd-file=/backup/etc/passwd /backup/etc / I understand your proposal. My point is that such an option would be awkward to implement because rsync accesses /etc/passwd via the C library, and it has no way to make the C library use a different file (except by chrooting), so rsync would have to reimplement the passwd-file parsing itself, which would be ugly. And I think I can simplify the chrooting approach a bit. Instead of setting up a daemon, you can use ssh to localhost with an --rsync-path that does the chroot: rsync -av --rsync-path='chroot /backup && rsync' localhost:/etc / Note that this does use the copy of rsync inside the chroot as the sender, just as if you pulled from the running machine over the network. FYI, to test this successfully on Fedora 9, I needed to have at least the following inside the chroot: rsync, its shared libraries (those shown by ldd plus /lib/libnss_files.so.2), the targets of the shared library symlinks, /etc/passwd, and /etc/group. The command could be simplified further if rsync gained a --chroot=PATH option that applies separately to each end of a local run (unlike the current implementation of --fake-super, which I think should be changed to this saner behavior): rsync -av --chroot=/backup /etc / (Maybe --no-numeric-ids would be necessary? I have no way to test.) Since a local run is treated as a push, the --chroot option would apply only to the sender. To apply it only to the receiver, one would use --remote-option=--chroot=/backup . Matt
signature.asc
Description: This is a digitally signed message part
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
