The magical world of containers — Linux background — cgroup and chroot
Anyone in my LinkedIn network knows last year I became a Certified Kubernetes Application Developer. After about 4 years working actively on Kubernetes day by day, this certification was a great recognition of my studies.
This is why I decided to start a new post series, describing what I’ve learned about containers and their use cases. Topics will be:
* Basic concepts
* Use cases
* Unix background
* Namespaces
* Control Groups
* chroot
* Implementations
* Docker
* containerd
* Orchestration and Docker Swarm
* Kubernetes
* Architecture
* Objects
* CLI
* Cloud Foundry
* Architecture
* Application development
* CLI
* OpenShift
* Architecture
* Objects
* CLI
Before starting, I would add a caveat: this is what I understood after studying on books and on the job, but could include lots of misunderstanding, so please use those posts just a starting point to deepen your knowledge, starting your own learning roadmap (and eventually point me to the misunderstandings)!
As said in my previous story, containers leverage some Linux kernel features in order to achieve process isolation.
In addition to namespaces, other features which allow to isolate a process into process space are cgroups and chroot
.
Cgroups
The term cgroup is the abbreviation of control group. This is a Linux kernel feature that limits, accounts for, and isolates resources’ usage (CPU, memory, disk I/O, network, etc.) of a collection of processes.
Engineers at Google (primarily Paul Menage and Rohit Seth) started the work on this feature in 2006, using process containers as first name, but in the late 2007, in order to avoid any mistake (the word “container” has multiple meanings in Linux kernel context), the feature started to use the name we know currently. First time control groups could be used in a Unix OS was in kernel version 2.6.24, which was released in January 2008.
If we would define briefly what is a control group, we could say that it’s a collection of processes that are bound by the same criteria and associated with a set of parameters or limits. These groups can be hierarchical, meaning that each group inherits limits from its parent group.
The kernel provides access to multiple controllers (also called subsystems) through the cgroup interface; for example, the “memory” controller limits memory use, “cpuacct” accounts CPU usage, etc.
chroot
chroot
on Unix operating systems is an operation that changes the apparent root directory for the current running process and its children. A program running in a modified environment like that (called chroot jail) cannot name (and therefore normally cannot access) files outside the designated directory tree.
Anyway, if you look for chroot
into Unix man
command, you could find two pages: one for chroot(2)
, a system call, and one for chroot(8)
, a wrapper program for that system call. That means we will continue to describe the system call, as the output derive from that.
A chroot
ed environment can be used to create and host a separate virtualized copy of the software system. In addition, it can be useful for testing and development, dependency control, compatibility, recovery, privileges separation.
It’s mandatory to highlight that chroot
mechanism is not intended to defend against intentional tampering by privileged users (typically root
user). On most systems, in fact, chroot
contexts do not stack properly and chroot
ed programs with sufficient privileges may perform a second chroot
syscall to break out.
To mitigate the risk of this security weakness, chroot
ed programs should relinquish root
privileges as soon as practical after chroot
ing, or other mechanisms — such as FreeBSD jails — should be used instead.