You can bind-mount directories into your chroot root with:
mount -o bind /x/y /chroot/x/y
(see man mount
, section "The bind mounts"). Any access to /chroot/x/y
from now on acts exactly like an access to /x/y
: same file listings, same contents, same inodes.
Note, however, that this puts the entire directory in as-is: a process inside the chroot that can write to the directory will be able to write to the "real" directory outside. If you want to make the mount inside the chroot read-only you need to remount explicitly read-only after the bind:
mount -o remount,ro /chroot/x/y
The original /x/y will remain read-write, but the copy will now be read-only.
To prefer internal copies of files, or to allow writing in some existing files or directories without affecting the originals, you can use a union file system. These let you overlay multiple directory trees on one another, specifying where writes go to and the order that reads are resolved. Common union filesystems for Linux include aufs, Unionfs, and unionfs-fuse. The first two of those are kernel modules, while the last uses FUSE to run a filesystem in user space. The kernel modules are generally faster, but the FUSE version may be easier to set up, although you may want to avoid using external user-space tools from your chroot anyway. You can prepare the union filesystems you want and then chroot into them.
In each case the basic approach is the same, something like:
unionfs-fuse -o cow /jail/bin:/other/bin:/bin /chroot/bin
This creates a union mount in /chroot/bin
which gives the files from /jail/bin
priority if they exist, then try /other/bin/
, and otherwise shows the files from /bin
. -o cow
makes it copy-on-write: attempts to write to, say, /chroot/bin/foo
will copy /bin/foo
to /jail/bin/foo
and save the modifications there. If you don't want that behaviour, leave the option out. The other filesystems have slightly different configurations, but the principle is the same.
Whichever way you set it up, you could then:
chroot /chroot
and have everything work the way you wanted.
There are a lot of reasons to use a chrooted environment, you can use it to keep different versions of one program, you can use it to simulate an specific environment in order to test some features, to create images of a system different from your main one, etc.
Wikipedia can tell you more about chroot jails and its usages.
From there:
Testing and development:
A test environment can be set up in the chroot for software that would otherwise be too risky to deploy on a production system.
Dependency control:
Software can be developed, built and tested in a chroot populated only with its expected dependencies. This can prevent some kinds of linkage skew that can result from developers building projects with different sets of program libraries installed.
Compatibility:
Legacy software or software using a different ABI must sometimes be run in a chroot because their supporting libraries or data files may otherwise clash in name or linkage with those of the host system.
Recovery:
Should a system be rendered unbootable, a chroot can be used to move back into the damaged environment after bootstrapping from an alternate root file system (such as from installation media, or a Live CD).
Privilege separation:
Programs are allowed to carry open file descriptors (for files, pipelines and network connections) into the chroot, which can simplify jail design by making it unnecessary to leave working files inside the chroot directory. This also simplifies the common arrangement of running the potentially vulnerable parts of a privileged program in a sandbox, in order to pre-emptively contain a security breach. Note that chroot is not necessarily enough to contain a process with root privileges.
Best Answer
An ordinary user can't create a setuid binary, but there's nothing preventing him from creating a hard link to an existing setuid binary. So if he has write permission to a directory on the same filesystem as
/usr/bin
, he can put the jail in this directory, create a hard link tosu
orsudo
in it, and put a custom/etc/passwd
and/etc/sudoers
in the jail.Maybe that won't work for
sudo
, as it might check that/etc/sudoers
is owned by root. But I'll betsu
doesn't check the ownership of/etc/passwd
.