restricting rsync over ssh on the server side.

[jw schultz]

On Sun, Jan 05, 2003 at 06:32:53PM -0600, Rob Browning wrote:
> 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.
why the "but"?  That is just what i said.
While i don't know the details of sftp, scp has ssh
executing a regular command over the link, mess up the path
and scp breaks.

> 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
> --server...
> 
> 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.

I'm just wondering what you are suggesting be added to rsync
that couldn't be done by the wrapper you already need.

You can already restrict --delete and check the paths rsync
will operate on to ensure they are within the designated
trees.  As it is rsync won't read or write anything
outside of a paths specified on the command line.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt