There are a number of documents about how to permit ssh access to run rsync or unison for remote synchronisation by an appropriate configuration of the authorized_keys file. Of these the best two are probably those by Stéphane Kattoor and Christian 'Greek0' Aichinger. Joey Hess also explains some of the pitfalls.

The problem is the familiar one: to limit the file-system hierarchy accessible. The humble chroot is a natural way to implement such restrictions which is probably what led "Greek0" to suggest the use of dchroot.

This is indeed a fine solution ... except, how does one implement it if one is not root on the server machine?

WARNING: The rest of this entry is wrong as was pointed out by Joey Hess. See the update at the bottom.

The package fakechroot by Piotr Roszatycki provides a way out.

The problem I had was as follows:

• I want to share a certain sub-tree of $HOME using unison.
• I am OK with sharing whatever access I give to /bin, /lib and /usr in the process.
• I do not have root access to the machine.

A recent enough version of fakechroot (version 2.8 worked) allows one to do make use of environment variables as follows:

LD_PRELOAD=libfakechroot.so
LD_LIBRARY_PATH=/usr/lib/fakechroot:/usr/lib64/fakechroot:/usr/lib32/fakechroot:/usr/lib:/lib
FAKECHROOT=true
FAKECHROOT_VERSION=2.8
FAKECHROOT_EXCLUDE_PATH=/bin:/lib:/usr
export LD_LIBRARY_PATH LD_PRELOAD
export FAKECHROOT_EXCLUDE_PATH FAKECHROOT FAKECHROOT_VERSION

After this setup one can run

HOME=/ chroot $HOME/some/dir /usr/bin/unison -server

and the unison server¹ will only be able to view /bin, /lib, /usr and $HOME/some/dir; the latter will be mapped to /. (One needs to set the $HOME variable to something sensible for unison to function.)

One should not be tempted to create subdirectories of $HOME/some/dir containing only the "relevant" portions of the system directories for unison. The reason is that those files will be created as me and so could be overwritten by unison.

The creation of a suitable entry in authorized_keys to use this is an easy exercise!

UPDATE: As Joey Hess has noted:

Taking a program, be it fakechroot or unison, that was never designed with security in mind, and trying to use it as a security barrier, is an open invitation to pain.

I had thought about the problem of uploading static-linked binaries and had imagined that it had been overcome. However, the basic facts in this case are:

• unison -server does not have an option to limit its view of the directory heirarchy. The upstream authors are aware of this but it is not clear whether they perceive it as a bug.
• fakechroot is meant to give a different view of the directory heirarchy to programs that use standard libc calls. It does not block access to part of the tree as the real chroot does; again, this is not necessarily a bug.