Frequently Asked Question

How is a container different from chroot?

chroot(2) has been in Unix since 1979 and does exactly one thing: it changes the apparent root directory of a process so it cannot name files outside the new root. That is useful, but on its own it is a very weak boundary. A chrooted process still sees every other process on the host (no PID isolation), still uses the host network stack (no network isolation), still has its real UID, can still send signals to host processes, and if it has root inside the chroot it has many well-known escape tricks. Chroot is a filesystem trick, not a sandbox.

A container is what you get when you take chroot (or its successor, pivot_root) and add PID, network, mount, UTS, IPC, user, and cgroup namespaces plus cgroups, capability drops, a seccomp filter, and usually an LSM policy. Each layer closes a different escape route. People sometimes call containers "chroots with a marketing budget", but that undersells how much each of those extra layers actually buys you. Chroot remains the right tool for build environments, package staging, and rescue shells; containers are the right tool when you want to run untrusted or noisy software next to other things.