There are a number of documents about how to permit ssh access
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'
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
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.
fakechroot by Piotr Roszatycki
provides a way out.
The problem I had was as follows:
- I want to share a certain sub-tree of
- I am OK with sharing whatever access I give to
/usrin the process.
- I do not have root access to the machine.
A recent enough version of
2.8 worked) allows one to do make use of environment variables as
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 server1 will only be able to view
$HOME/some/dir; the latter will be mapped to
/. (One needs to set the
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
reason is that those files will be created as
me and so could be overwritten by
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 -serverdoes 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.
fakechrootis meant to give a different view of the directory heirarchy to programs that use standard
libccalls. It does not block access to part of the tree as the real chroot does; again, this is not necessarily a bug.
For those trying this out at
$HOMEwith some terminal command like
/usr/bin/unisona suggestion is to add
FAKEROOT_EXCLUDE_PATHvariable so that you have access to your terminal. Be aware that giving remote access to
/devmay have unintended consequences! ↩