On Thu, 2007-12-06 at 09:55 -0500, Doug Lochart wrote: > Each client creates its own SSH tunnel via port forwarding. The > rsync client then sets the target to localhost and the local port of > the tunnel. The remote end is port 873 of the rsync server machine > with a daemon running. Each user has there own module. I can post > the rsyncd.conf if that would help.
I see. Posting the rsyncd.conf might be helpful in case it brings to light anything else we need to discuss. > One of our requirements is that the backup process has to be hands off > (no user interaction whatsoever). OK. The single-use daemon approach will give you this too; in fact, the client script will be the same except no port forwarding and an `-e "ssh -l <sshuser>"' option to rsync. > 1) Is it ok to manually put in --server? The rsync docs explicitly > say not to do it. Yes; this is not "normal circumstances". :) > 2) In this approach I do NOT have a daemon running on the server > correct? It is just that each invocation starts an rsync server in > daemon mode to handle that client correct? Correct. > 3) In your above approach what would stop a clever person from > hacking the client script and changing the rsyncd.conf to match > another clients? All rsyncd.conf files are on the backup machine. The forced commands ensure that the only thing a user can do with her ssh access is run an rsync daemon and access modules in accordance with the rsyncd.conf that you have set up for her. There is no way for her to modify the rsyncd.conf files or change her forced command to use a different user's rsyncd.conf file. The protections apply regardless of how she might change her client script. > The basic daemon approach runs as root and then just applies uid/gid > from the module to files sent but does not run as that user. When the > daemon is run by your approach is it running as the user and not root? > If so then unix permissions would come into play and the security hole > closed. Yes, if you have each user log into his/her own account with ssh, the daemon will run in that account. That is a second level of protection in addition to the forced command that mandates an rsyncd.conf file containing only the user's own module. But note that since you will be using a writable rsync daemon that can't chroot (because it is not running as root), you should either refuse --links or use a copy of rsync that supports symlink munging so that the following recently discovered vulnerability does not nullify the forced-command protection: http://rsync.samba.org/security.html#s3_0_0 Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html