chroot

Run command as new root directory

$ sudo chroot [path/to/new/root] [command]

$ sudo chroot --userspec [username_or_id:group_name_or_id]

chroot NEWROOT [COMMAND...]
chroot [OPTION]

NEWROOT
    Specifies the path to the directory that will serve as the new root (/) for the executed command and its descendants. This directory must exist and contain the necessary binaries and libraries for the command to run.

[COMMAND...]
    An optional argument specifying the command and its arguments to execute within the chroot environment. If no command is provided, chroot will attempt to run the shell specified by the SHELL environment variable, or default to /bin/sh if SHELL is not set or its value is not found.

--help
    Displays a help message and exits.

--version
    Displays version information and exits.

The chroot command in Linux stands for "change root" and is used to change the apparent root directory for the current running process and its children. This means that a program executed within a chroot environment will perceive the specified NEWROOT directory as the system's root (/).

This utility provides a basic form of process isolation, often referred to as a "chroot jail" or "chroot environment." Its primary uses include system recovery and maintenance (e.g., repairing a broken bootloader), building software packages in a controlled environment, running older or different distributions, and providing a rudimentary sandbox for applications. While it offers a degree of isolation by restricting file system access to a subset of the actual file system, it's crucial to understand that it does not create a new kernel or provide true virtualization. Processes inside the chroot still share the host system's kernel and resources.

While chroot offers file system isolation, it is not a robust security mechanism for sandboxing untrusted applications. Key limitations include:
- Kernel Sharing: Processes within a chroot environment share the host system's kernel. A root user inside the chroot can still perform operations like mounting/unmounting file systems, loading kernel modules, or accessing raw devices, which could compromise the host system.
- Escaping: Experienced attackers or malicious processes with root privileges inside a chroot might be able to escape the jail, for instance, by using nested chroot calls or specific system calls.
- Resource Isolation: chroot does not isolate other system resources like network interfaces, process IDs (PIDs), or inter-process communication (IPC).
- Dependency Management: The NEWROOT directory must contain all necessary binaries, libraries, device files (e.g., /dev/null, /dev/urandom), and configuration files that the executed COMMAND and its dependencies require. This often involves copying or bind-mounting these files into the new root, which can be complex.
- Privilege Requirement: Only the root user can execute the chroot command.

chroot is commonly used for:
- System Recovery: Booting from a live CD/USB and chrooting into the installed system to repair broken packages, modify configuration files, or reset passwords.
- Software Compilation: Building software in a clean, isolated environment to ensure consistent dependencies and prevent interference with the host system.
- Security Auditing: Running untrusted applications in a somewhat isolated environment, though it's not a full security sandbox.
- Multi-arch Development: Setting up environments for different CPU architectures (e.g., ARM development on an x86 machine) by populating the NEWROOT with the appropriate binaries.

For a command to run successfully inside a chroot, the NEWROOT directory must be self-contained. This typically involves:
- Core Binaries: Copying essential binaries like /bin/sh, /bin/ls, /bin/cat, etc., and their required shared libraries (often found in /lib, /lib64, /usr/lib). The ldd command can help identify library dependencies.
- Device Files: Creating or bind-mounting necessary device files (e.g., mknod /dev/null c 1 3 or mount --bind /dev /newroot/dev).
- Configuration Files: Copying relevant configuration files (e.g., /etc/resolv.conf for DNS).
- Mount Points: For certain operations, mounting virtual filesystems like /proc and /sys inside the chroot (e.g., mount --bind /proc /newroot/proc) might be necessary.

The underlying chroot system call has a long history, first appearing in Version 7 Unix in 1979. It was primarily designed for system administration tasks, such as creating isolated environments for compiling software or recovering a broken system. The chroot command-line utility provides a user-friendly wrapper around this system call, making it accessible to system administrators. While its core functionality remains unchanged, its role has evolved. It laid some groundwork for more advanced containerization technologies like Docker and LXC, which build upon similar isolation principles but offer more comprehensive and secure sandboxing by leveraging Linux kernel namespaces and cgroups.

mount(8), pivot_root(8), unshare(1), systemd-nspawn(1), namespaces(7)