restricting rsync over ssh on the server side.
rlb at defaultvalue.org
Mon Jan 6 00:33:00 EST 2003
jw schultz <jw at pegasys.ws> writes:
> A general purpose wrapper could be done but you would have to have
> ways to tell it to require these options, disallow these options,
> which of those options require args, and what arguments must match
> what patterns. A full implementation would probably need a config
> file per invocation.
> I'd say this topic is really better suited to the openssh list. The
> outcome, if useful, i think would be worth a link on the rsync
> resources page.
Perhaps so, but in the case of at least ssh (as compared to sftp or
scp), the problem seems to be much more general, probably requiring an
LD_PRELOAD or chroot solution since via ssh you can run any command.
On the other hand with rsync and a fixed command="foo" key that limits
the incoming user's command to an rsync-wrapper invocation, as long as
rsync has it has a clear idea of every place it uses a path, it seems
like supporting a --root=foo option when running as --server might be
fairly straightforward. I would guess that the main tricky bits would
be handling (quashing) out-of-root symlinks and .. references safely.
For those interested, the reason I started thinking about this was
that I wanted to back up some machines via duplicity to their local
disk, and then rsync each one to a central server. I wanted to make
sure that each machine could only rsync to its own area, had no other
access to the machine, and I didn't want to have to have one system
account per client on the backup host.
Although I think a rsync command designed to work with ssh's
command="foo" facility might be fairly useful, and I might revisit
this topic later, I think I'm going to first try to make time to fix
the similar issue in duplicity where the problem is somewhat simpler
because duplicity has a strict separation between its front and back
ends and only requires the backends to implement the list, put, get,
and delete commands.
See the duplicity-talk list for the recent details, but something
similar to the following might eventually be interesting for rsync
On the backup server you'd have:
from="host-1.foo.bar",command="/usr/bin/duplicity-ssh-backend --append-only --root /backup/dup/host-1"
from="host-2.foo.bar",command="/usr/bin/duplicity-ssh-backend --append-only --root /backup/dup/host-2"
from="host-3.foo.bar",command="/usr/bin/duplicity-ssh-backend --append-only --root /backup/dup/host-3"
duplicity-ssh-backend will be responsible for implementing duplicity's
server-side actions, making sure that each host is only be able to add
to its current backup set, and is only able to write beneath the given
root. duplicity-ssh-backend will look in SSH_ORIGINAL_COMMAND to see
what action the duplicity client is requesting. The client will run
requests that look something like this:
ssh -i ident user at host duplicity-ssh-backend list
ssh -i ident user at host duplicity-ssh-backend put DESTINATION < datafile
ssh -i ident user at host duplicity-ssh-backend get SOURCE
ssh -i ident user at host duplicity-ssh-backend delete DESTINATION
and in each case, on the server side, the invocation of
duplicity-ssh-backend via the command="..." key option will examine
SSH_ORIGINAL_COMMAND and see the relevant "put DESTINATION" or "get
SOURCE" request, etc. and then decide based on that and its own
command line options (i.e. the --root and --append-only options above)
whether or not to allow and attempt the operation.
duplicity-ssh-agent will probably accept the "put" files on stdin,
return the "get" files on stdout, and return as much error information
as needed on standard error.
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
More information about the rsync