Let's starting by typing
man chroot in a linux terminal and see what we get
chroot - run command or interactive shell with special root directory.
chroot [OPTION] NEWROOT [COMMAND [ARG]...]
~ Linux manual
So what really is chroot?
Chroot is a unix command that changes the root directory of COMMAND to NEWROOT specified in parameters. A very simple use case is:
chroot ~/Downloads ls -la
Looking at the previous command and the definition of chroot one would say that this command will:
1- change root to Downloads, cd to Downloads
ls -la inside Downloads and print out Downloads directory content
While this thinking process is correct, this command will actually fail for two reasons. The first reason this command will fail is because chroot needs root access and will fail without root permissions. If this didn't happen to you then you probably copy pasted a command from the internet that you don't understand and ran it with root permissions and if I were you I would spend sometime thinking about my life choices.
The second reason, after fixing the root permissions, is that the shell won't be able to execute
ls -la in the new root directory because it won't find it under
/bin/ls and this demonstrates a powerful feature of chroot. Chroot does more than a simple cd into a directory. Chroot changes what
/ means for the running process. In our example the shell will look for
ls in ~/Downloads/bin/ instead of / because chroot changed the root to be under Downloads directory.
Let's try this one more time but after making
ls available in the new root.
mkdir -p ~/Downloads/bin/ cp /bin/ls /Downloads/bin // make sure to make all dependencies available too // for simplicity, will make all shared libs available but for better context use `ldd` to get dependencies of a specific command. sudo cp -a /usr ~/Downloads sudo cp -a /lib ~/Downloads sudo cp -a /lib64 ~/Downloads sudo chroot ~/Downloads ls -la
Now that we made
ls available to the new root living in
~/Downloads/bin/ls, command will output the content of Downloads directory.
You might have noticed that
COMMAND argument is optional in chroot. By default, chroot runs
$SHELL in the new root which will also fail if you don't have the shell executable available under
Testing and development: A test environment can be set up in 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).
Worth noting: if the topic got your interest and you went to search for more content about the topic you might find people refering to chroot as
chroot jail and this is slightly incorrect because chroot can't be used as a security measure. It simulates a separate environment but a process that knows it's running under a chroot environment can escape the environment.