remote logging non-daemon mode
matt at mattmccutchen.net
Thu Dec 6 21:55:00 GMT 2007
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?
> 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
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:
More information about the rsync