Check: Linux isolation

To the host kernel, a container is a process with an ordinary PID in the shared process table. What makes it special is its configuration: its own namespaces, a cgroup with limits, trimmed-down capabilities, and a root filesystem from the image. On Linux you can see it in ps on the host. On macOS and Windows, Docker Desktop keeps a Linux VM, and the process lives there, so it's easier to look through docker top (lesson container as a process, lab 1).

Namespaces decide what a process can see. Cgroups decide how much CPU, memory, IO, and how many processes it gets. These are two independent kernel mechanisms: you can remove either one, and the other keeps working.

The list of namespaces for a process in a container:

docker run --rm --label izi.lab=li04-quiz --memory 32m alpine:3.20.3 ls /proc/self/ns

cgroup
ipc
mnt
net
pid
pid_for_children
time
time_for_children
user
uts

Memory isn't in this list. The memory limit lives in a cgroup file (this is cgroup v2):

docker run --rm --label izi.lab=li04-quiz --memory 64m alpine:3.20.3 cat /sys/fs/cgroup/memory.max

67108864

That's 64 x 1024 x 1024 bytes.

A system call from a container is handled by the host kernel. A virtual machine loads its own kernel and runs on top of a hypervisor. That's also where the isolation boundary differs: a vulnerability in the host kernel affects every container on it, while guest kernels of virtual machines are separated from each other. The second option is wrong because of the word "always": pure CPU-bound computation in both cases runs on the same processor with almost no overhead.

Compare the Docker host's kernel with what a process in the container sees:

docker info --format '{{.KernelVersion}}'

5.15.49-linuxkit

docker run --rm --label izi.lab=li04-quiz --memory 32m alpine:3.20.3 uname -r

5.15.49-linuxkit

The versions match. On macOS this is the kernel of Docker Desktop's Linux VM, not the macOS kernel: containers live inside that VM and share its kernel.

By default Docker leaves a container 14 capabilities out of roughly forty. For example, CAP_SYS_ADMIN isn't in that set, so mounting a filesystem from inside won't work. A user namespace goes further: UID 0 inside maps to an ordinary UID on the host. In Docker this isn't enabled by default, the mode is called userns-remap and is configured in the daemon. The third option is wrong: root is allowed in a container and by default the process runs as root. The fourth is wrong too: its own PID namespace hides the host's processes.

The effective permission mask of a process in a container by default:

docker run --rm --label izi.lab=li04-quiz --memory 32m alpine:3.20.3 grep CapEff /proc/1/status

CapEff:	00000000a80425fb

For root on the host, every bit the kernel knows about is set in this mask. How to decode the mask into names is covered in the lesson container as a process, the "capabilities" section.

Without --memory, the container's group has max in its memory.max file, meaning there's no ceiling. A leak inside such a container keeps growing until the whole host runs out of memory, and then the kernel's OOM killer picks a victim among all processes, including other containers. With a limit, the OOM killer fires inside the container's own group, and neighbors aren't affected.

docker run --rm --label izi.lab=li04-quiz alpine:3.20.3 cat /sys/fs/cgroup/memory.max

max

--memory is deliberately left out here: this is what a container with no ceiling looks like.