The roots of containers

Ask the average user what a Docker container is and you might get any one of a dozen responses. You might be told something about lightweight virtual machines, or how it is that this hot new disruptive technology is going to revolutionize computing. In reality, Linux containers are certainly not a new idea, nor are they really all that much like a virtual machine.

Back in 1979, the chroot syscall was added to Version 7 of Unix. Calling chroot changes the apparent root directory for the current running process and its subprocesses. Running a program in a so-called chroot jail prevents it from accessing files outside of the specified directory tree.

One of the first uses of chroot was for testing of the BSD build system, something that is inherited by the package build systems of most of our modern Linux distributions, such as Debian, RedHat, and SuSE. By testing packages in a clean chrooted environment, build scripts can detect missing dependency information.

Chroot is also commonly used to sandbox untrusted processes-for example, shell processes on shared FTP or SFTP servers. Systems designed specifically with security in mind, such as the Postfix mail transfer agent, utilize chroot to isolate individual components of a pipeline in order to prevent a security issue in one component from rippling across the system.

Chroot is in fact a very simple isolation tool that was never intended to provide either security or control over anything other than the filesystem access of the processes. For its intended purpose of providing filesystem isolation for the likes of build tools, it is perfect. But for isolating applications in a production environment, we need a little more control.