Up till now, I've only used blogging as a way to keep in touch with friends and family members. One thing that I have noticed while doing so is that contrary to what I've felt in the past, not all of my acquaintances are interested in Linux or even in technology. Any tech-based blog entries I've created in my family's blog have gone largely ignored and I've even been asked (nicely) _not_ to pollute the blog with my Linux fanaticism. :) Consequently, I've decided to jump on the Guru Labs bandwagon and move all technospeak to this blog.
Without further stalling, let the blogging commence...
CHROOT
Without further stalling, let the blogging commence...
CHROOT
During my adventures with Linux, I've often seen some pretty powerful uses
for the "chroot" command. Being new to Linux/Unix, I had no idea what it
accomplished, but like many users, ran it blindly trusting that it would help
me accomplish whatever a particular tutorial was outlining.
Since coming to work at Guru Labs, I've had several chances to explore
chroot a bit more and have made some (hopefully) useful observations:
1. chroot can be used as a security mechanism
2. chroot can be used to troubleshoot a broken Linux installation
3. chroot can be used to make major modifications to a Linux installation that
couldn't otherwise be made
4. chroot can be used for testing in an isolated environment
5. chroot can be used to run 32-bit apps inside of a 64-bit Linux environment
6. chroot can be used in many other ways that I haven't currently seen
Before exploring any of the aforementioned areas where chroot is useful, a short
explanation of chroot is necessary.
As chroot(2) (the Linux man page viewed by running "man 2 chroot") points out,
"chroot() changes the root directory of the calling process to that specified in
path. This directory will be used for pathnames beginning with /. The root direc‐
tory is inherited by all children of the calling process."
Now, the following example could prove useful if the above description wasn't obvious.
Personally, what chroot accomplished or why I should care wasn't apparent to me until I had
experimented with chroot a few times.
Let's assume that I've got a filesystem that looks like this:
tgelter ~ $ tree -L 1 /
/
|-- bin
|-- boot
|-- dev
|-- etc
|-- home
|-- lib
|-- lib64
|-- media
|-- mnt
|-- oldroot <--specifically notice this one
|-- opt
|-- proc
|-- root
|-- sbin
|-- srv
|-- sys
|-- tmp
|-- usr
`-- var
Now, excluding a lengthy conversation about Linux having a singly-rooted inverted-tree
filesystem structure, let it suffice to say that several individual filesystems are
currently "mounted" and grafted together as we can see from running the "mount" command:
tgelter ~ $ mount
/dev/sda2 on / type jfs (rw)
none on /dev type ramfs (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
none on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/mapper/storage on /storage type xfs (rw,noatime)
/dev/mapper/oldroot on /oldroot type ext3 (rw,noatime)
Specifically, I have a filesystem on device "/dev/mapper/oldroot" mounted to the directory
called "/oldroot". This filesystem happens to be an older installation of Linux which I'm
no longer using but keeping around in case I happen to need to copy over an old config file
or, in the worst case scenario, I can boot to it if my current installation were badly broken.
Looking at the directory listing of "/oldroot", we see that it has many of the same
directories of my currently running system:
tgelter ~ $ ls /oldroot/
backup boot etc lib lost+found mnt proc sbin storage tmp var
bin dev home lib64 media opt root srv sys usr
Now let us consider the scenario where I'm attempting to fix "/oldroot". After some research,
I've determined that I just need to issue a system upgrade in order to fix networking. If I
were to boot into "/oldroot" to fix the issue, networking would be broken and there would be
no way to perform the system upgrade in order to fix networking. (Yeah, I _could_ download the
needed packages and install them offline, but let's pretend that's not possible :) )
In order to perform the upgrade, the following steps could be taken:
1. Bind mount virtual filesystems that will be needed by the new chroot environment (a "bind mount" takes a directory that is already mounted and mounts it somewhere else at the same time):
root ~ # mount --bind /proc /oldroot/proc
root ~ # mount --bind /dev /oldroot/dev
root ~ # mount --bind /sys /oldroot/sys
(more may be needed depending on your configuration)
*note - these need to be mounted prior to entering the chroot so that your
new working environment will be able to obtain information about hardware,
running processes, etc.
2. Chroot into the new environment:
root ~ # chroot /oldroot/
When I issue this command, the shell (in this case, bash) as well as any
processes created by it, see the "/dev/mapper/oldroot" filesystem which we saw
mounted to "/oldroot" as the new "/"
root / # tree -L 1 /
/
|-- backup
|-- bin
|-- boot
|-- dev
|-- etc
|-- home
|-- lib
|-- lib64
|-- lost+found
|-- media
|-- mnt
|-- opt
|-- proc
|-- root
|-- sbin
|-- srv
|-- storage
|-- sys
|-- tmp
|-- usr
`-- var
You may notice that "/oldroot" no longer appears as it is now referred to as "/".
Before chrooting, each of these directories was located under "/oldroot/". To help
visualize,
/oldroot/etc --> /etc
/oldroot/home --> /home
/oldroot/backup --> /backup
etc.
3. Fix networking as necessary:
(in my case, I just need to overwrite my /etc/resolv.conf to properly
resolv hostnames. _DON'T RUN THIS UNLESS YOU KNOW WHAT YOU'RE DOING_)
root / # cp /etc/resolv.conf /etc/resolv.conf.bak && echo "nameserver 4.2.2.2" > /etc/resolv.conf
4. Perform the upgrade (I'm using ArchLinux):
root / # pacman -Syu
:: Synchronizing package databases...
testing is up to date
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (9): e2fsprogs-1.41.3-2 expat-2.0.1-2 git-1.6.0.3-1 gvfs-1.0.2-1 kismet-2008_05_R1-1
libdrm-2.4.0-1 openoffice-base-3.0.0-2 kernel26-2.6.27.1-1
Total Download Size: 154.91 MB
Total Installed Size: 367.04 MB
Proceed with installation? [Y/n] y
I happen to use Arch Linux on my laptop, so the system upgrade procedure on your own
machine will almost certainly differ from what I did above (perhaps "yum upgrade" for
Fedora/RHEL, "aptitude dist-upgrade" for debian/ubuntu, etc.).
5. Exit the chroot:
root / # exit
6. Unmount the virtual filesystems:
root ~ # umount /oldroot/{dev,proc,sys}
Assuming that I had a bad kernel which has now been updated, I could now reboot into the
old installation using the new kernel to test if my fix worked.
Now, I mentioned several reasons to use chroot: 1. A security mechanism, 2. To troubleshoot
a broken Linux installation, 3. To make major modifications to a Linux installation that
couldn't otherwise be made, 4. For testing an isolated environment, 5. Used to run 32-bit apps
inside of a 64-bit Linux environment, 6. Used in many other ways that I haven't currently seen
The example I went over is a fairly common example of reason #2 mentioned above. Most Linux
rescue media uses a similar procedure for rescuing a broken system. I won't go into detailing
any of the other reasons, but see the included URL for reading related to each reason as
numbered above:
1. http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide/Servers/DNSBIND/BINDChroot
3. http://www.howtoforge.com/install-ubuntu-with-software-raid-10
4. https://help.ubuntu.com/6.10/ubuntu/installation-guide/amd64/linux-upgrade.html
5. http://wiki.archlinux.org/index.php/Arch64_Install_bundled_32bit_system
One last note about item #1, placing a process inside of a chroot "jail" as a security
mechanism is often criticized as we see here: http://kerneltrap.org/Linux/Abusing_chroot
from man chroot(2):
"In particular, the superuser can escape from a "chroot jail" by doing:
mkdir foo; chroot foo; cd .."
The thing to keep in mind is that chroot is _not_ as powerful as freebsd's jail(). This doesn't
mean that there is no value in placing a process, especially a network service, into a chroot.
Like all security, multiple layers means more protection.
If you've read this far and still have interest in researching security through chroot, I'd
recommend you look into a couple of better solutions which are available:
-linux vserver (attempt at improving the chroot jail idea)
-virtual machines (kvm/xen/etc.)
