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
usingunison
. - 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 server1 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 standardlibc
calls. 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
$HOME
with some terminal command like/bin/sh
instead of/usr/bin/unison
a suggestion is to add/dev
to theFAKEROOT_EXCLUDE_PATH
variable so that you have access to your terminal. Be aware that giving remote access to/dev
may have unintended consequences! ↩