The chroot wrapper script (chw) is a very simple tool which wraps some of the
tedium of using a chroot in an automated way.
My typical modus operandi when working on various development projects is to
isolate my development/build environments away from my host environment. I
realize this is nothing shocking, or amazing, or unique, and that most good
developers do this practice... but whatever...
Depending on what I'm working with, there's a variety of tools I can use to
isolate my work (e.g., virtualenv for Python). However, the "nuclear option"
for environment isolation is the classic chroot(8).
The big problem when working with chroot is the fact that, in order for your
chroots to be useful, you need to set up various things (like mounts) inside
of them. When you get busy with multiple chroots running, and multiple shells
into them, it can become kind of hard knowing when and how to dismantle
these setups when you're done with a given chroot. This is especially difficult
when you need to discard a chroot entirely (there are few things worse than
doing an "rm -fr" on a chroot that still has /dev, /sys, and /proc mounted).
The chroot wrapper (chw) attempts to solve these problems by wrapping the
enabling and disabling of chroots as you use them.
Once you have a chroot built (chw will not build chroots for you, it assumes
you already have properly built chroots), you simply use it as root instead of
the "chroot" command:
chw.sh /some/path/to/the/chroot
The path can be relative or absolute. It can cross filesystem boundaries, and
be any format normally usable by chroot.
Wrap every shell instance you want into your chroot with this command. When you
are done, just "exit" as usual and chw will clean things up for you once every
instance is finished.
The chw script will display logging information to stdout telling you what it
is doing. This can be used as a verification of when the chroot environment
has been setup and cleaned up (even when the cleaning happens after a
different chw instance).
You'll need the following things (they should be found on many modern *nixes,
Linux certainly, but possibly Mac OS, who knows? I'd rather fellate an angry
rhino than own a Mac- Yes, I realize that's a dickish thing to say, that was
my intent):
(really standard stuff you'll find on many *nixes)
Crap, you people really are demanding, aren't you?
Copy the chw.sh script somewhere in your path. If I ever feel a need to make
an installer, I'll add it to the repo (and update this text). But that isn't
looking likely.
FINE! Installer added. Of course, I was getting sick of doing it manually.
Configuration? Nope. It's crazy stupid simple.
Debugging? Well, there's stuff can be found in /tmp/chw_work, but I wouldn't
recommend snooping there (and would advice against modifying anything in there)
unless you know what you're doing.
Frankly, I don't want to document how it works, so if you're curious, look at
the damned code.
Sure it can. Just like chroot.
But seriously, I just use it for development environments. Beyond that, I'd
recommend against using this or chroot for anything remotely resembling a
security purpose.
Probably. There's no locking (and I have no intent to add it any time soon),
so be careful not to launch multiple chw's (or exit multiple ones) at the
exact same time. You can run multiple ones at once, of course (that's kind
of the point), but just be sure you stagger their execution a bit.
Honestly, the worst things that will happen if you don't stagger them a bit
will be chroots not properly setup or torn down, and chw work environment
artifacts (e.g., worst case scenario shouldn't be too bad, provided you don't
do something really stupid elsewhere).
Also, chw kind of assumes bash will be in the chroot (it adds crap to a
.bashrc in there). It probably would work without it, however, as it'll just
leave a file in there that wont be used.
Use at your own risk, and be smart about it. Obviously, there's no warranty or
protection against the user using the script incorrectly.