5.1 容器原理：隔离、限制与镜像

第 2 篇你写过 fork、execve、openat；第 3 篇看过 task_struct、页表、VFS；第 4 篇跟过一个包从网卡到 socket。这四篇合起来，已经包含「容器」所需的全部内核零件。容器没有新增任何系统调用：它只是把这些零件按一种特定方式组合起来。

组合的目标是让一组进程以为自己在独占一台机器。要制造这种错觉，需要同时改写三样东西：进程能看见什么（namespace）、进程能用多少（cgroups）、进程脚下的文件系统长什么样（rootfs + overlayfs）。三样缺一不可，而且都不改变「进程就是一个普通 task_struct」这件事。

这一章先把三件套的整体关系立起来，并亲手搭一个最小容器；namespace 的细节留给 5.2，cgroups 留给 5.3，overlayfs 留给 5.4。读完这一章，你应该能在看到 docker run 时，脑内自动展开成「clone 一串 CLONE_NEW* → 写 cgroup 文件 → pivot_root → execve」。

5.1.1 容器不是虚拟机：共享内核的那条线

先看一个最直接的证据。在一台运行着容器的 Ubuntu 24.04 上：

# 宿主机
uname -r
# 6.8.0-xx-generic
docker run --rm busybox uname -r
# 6.8.0-xx-generic

容器里的 uname 读到的是同一个内核版本号。/proc/version、/proc/cpuinfo、/sys/devices 也都是同一份内核数据的不同投影。没有第二份内核，就没有虚拟机的「客户机」概念。

虚拟机（virtual machine, VM）走的是另一条路：hypervisor 用硬件虚拟化（VT-x/AMD-V）造出一台假机器，里面装一个完整的 guest 内核，再在 guest 里跑进程。容器不模拟硬件，它让宿主机内核在同一个内核里同时维护多套「视图」。这条区别决定了后面所有的性能与安全结论。

这张表最后两行是重点：容器的隔离强度上限由宿主内核决定。内核里一个可被容器内进程触发的提权漏洞，会影响这台机器上的所有容器。这也是为什么「容器里跑不可信代码」需要额外加固（5.1.7 展开），而不能拿虚拟机的标准来类比。

读图时注意左右两列的对应关系：左列是内核机制，右列是容器内观察到的效果。PID namespace 让容器里的 ps 只看到自己这一棵进程树；mount namespace 让 / 指向 overlayfs 的 merged 目录；cgroups v2 决定这个容器最多能用多少 CPU 与内存。图的最后一行写明了根本区别：没有独立内核，隔离靠内核提供，共享内核也意味着共享漏洞面。

5.1.2 三件套：各管一段，缺一不可

把「独占一台机器」拆成三个具体问题，对应三个机制：

再补一件常被忽略的「第四件套」：权限收窄。capabilities、seccomp、no_new_privs、LSM（AppArmor/SELinux）决定容器里的 root 能做什么。没有它，前三件套只是「看不见」，不是「动不了」。

三件套的组合方式可以用一句话概括：namespace 决定「看得到」，cgroup 决定「用得到」，rootfs 决定「摸得到」。三者独立：只加 namespace，容器能看见自己的 / 但可以吃光宿主内存；只加 cgroup，资源被限住但进程仍能看见宿主所有进程；只换 rootfs，文件系统隔离了但 ps 还是全量。

它们也没有被设计成一个「容器开关」。namespace 早于容器十几年，cgroup 最初是为了给「一组进程」做资源核算，overlayfs 是为了 Live CD 与联合挂载。容器是把三套通用机制按一份配置组合起来的结果——这也解释了为什么 OCI 标准描述的是「配置」而不是「实现」：只要组合结果一致，用 runc、crun 还是 Kata（后者其实加了虚拟机）都能满足同一份 config.json。

5.1.3 从 chroot 到 pivot_root：换掉脚下的根

容器文件系统隔离的起点是 chroot(2)：把进程的根目录改成某个目录。它诞生于 1979 年，比容器这个词早得多。但 chroot 有三个硬伤：

• 它只改 fs_struct 里的 root 与 pwd，不改 mount namespace；进程仍能看到宿主的所有挂载点（通过已打开的 fd、或 .. 之外的绝对路径）。
• 拥有 CAP_SYS_CHROOT 的进程可以再次 chroot 跳出；如果进程持有指向旧根的 fd，也能 fchdir 回去。
• 它不隐藏 /proc：/proc/1/root 仍指向宿主根，容器里的进程可以顺着读。

pivot_root(2) 解决的是「换根」这件事在挂载树层面的正确性：它把当前根挂载整体移到 put_old，把 new_root 提升为新的根挂载，然后你可以 umount 掉旧根。整个过程发生在调用者的 mount namespace 内，配合 CLONE_NEWNS 就不会影响宿主。

pivot_root 之前（容器进程的 mount namespace）
​
  /            ← 宿主根挂载（shared，会传播）
  ├── proc
  ├── sys
  ├── home
  └── mnt/rootfs   ← 准备做新根（必须是挂载点）
​
pivot_root(".", ".oldroot") 之后
​
  /            ← 新根：mnt/rootfs 这一棵
  ├── proc     ← 在 rootfs 内重新 mount 的 proc
  ├── bin
  └── .oldroot ← 旧根被叠到这里，可 umount -l 摘掉

读这张布局图要抓住两点：新根必须先成为一个挂载点（否则 pivot_root 返回 EINVAL），旧根必须被移到新根之下（put_old 要在 new_root 里面）。所以标准动作是：mount --bind rootfs rootfs 造挂载点 → pivot_root(rootfs, rootfs/.oldroot) → umount2("/.oldroot", MNT_DETACH)。

在写代码前，还有一个容易翻车的细节：挂载传播。现代 systemd 发行版把 / 设为 shared，你在容器 mount namespace 里执行的 mount 会沿着 shared 关系传播回宿主。所以进入新 mount namespace 后的第一件事通常是：

# 需要 root；在新建的 mount namespace 内执行
mount --make-rprivate /

--make-rprivate 递归地把整棵挂载树改成 private，切断与宿主的传播。少了这一步，容器里的 mount -t proc 可能把宿主的 /proc 覆盖掉——这是「手工搭容器」最常见的事故。

5.1.4 手工搭一个最小容器（root，Ubuntu 24.04）

下面不用 Docker，只用 util-linux 的 unshare、mount 与 busybox，做一个具备 PID/mount/UTS/net 隔离、独立 /proc 与独立根文件系统的「容器」。它没有 cgroup 限额、没有 capabilities 收窄、没有 seccomp——那三样在 5.3 与 5.5 补。

第一步：准备一个静态 rootfs

# 需要 root；安装静态 busybox 并搭建最小根目录
sudo apt-get update
sudo apt-get install -y busybox-static

sudo mkdir -p /tmp/minic/rootfs/{bin,proc,sys,dev,tmp}
sudo cp /bin/busybox /tmp/minic/rootfs/bin/
for applet in sh ls cat echo mount ps id hostname sleep; do
    sudo ln -sf busybox "/tmp/minic/rootfs/bin/$applet"
done

busybox-static 是静态链接的单二进制，不依赖宿主 glibc，因此可以直接放进空 rootfs。若你更想用真实发行版的文件树，可以 docker export $(docker create busybox) -o rootfs.tar 再解包，效果相同。

第二步：写进入脚本

#!/bin/bash
# minicont.sh — 用 unshare + pivot_root 手工起一个容器；需要 root
set -euo pipefail
ROOTFS=${1:?usage: minicont.sh ROOTFS}
export ROOTFS

unshare --mount --uts --ipc --pid --net --fork --kill-child \
  /bin/bash -euo pipefail -c '
    rootfs=$ROOTFS

    # 1. 切断挂载传播，避免污染宿主
    mount --make-rprivate /

    # 2. 新根必须先成为挂载点
    mount --bind "$rootfs" "$rootfs"

    # 3. 在 rootfs 内准备伪文件系统
    mount -t proc  proc  "$rootfs/proc"
    mount -t sysfs sysfs "$rootfs/sys"
    mount -t tmpfs tmpfs "$rootfs/tmp"

    # 4. 换根：旧根叠到 .oldroot，再摘掉
    cd "$rootfs"
    mkdir -p .oldroot
    pivot_root . .oldroot
    umount -l /.oldroot
    rmdir /.oldroot

    # 5. 设置 UTS 主机名，exec 用户进程（PID 1）
    hostname minic
    exec /bin/sh
'

逐段解释：

第三步：运行与观察

# 需要 root
sudo chmod +x /tmp/minic/minicont.sh
sudo /tmp/minic/minicont.sh /tmp/minic/rootfs

进入后可以验证四件事：

/ # id
uid=0(root) gid=0(root) groups=0(root)
/ # hostname
minic
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 /bin/sh
    5 root      0:00 ps
/ # ip -brief addr
lo               UNKNOWN        127.0.0.1/8
/ # cat /proc/1/status | head -3
Name:   sh
Umask:  0022
State:  S (sleeping)

四个观察分别对应四个 namespace：ps 只有两个进程（PID namespace）；hostname 是 minic（UTS namespace）；ip addr 只有 lo（network namespace）；/ 下只有 busybox 的目录（mount namespace + pivot_root）。此时你在宿主上另开一个终端，ps -ef | grep minicont 能看到这个 sh，它有一个宿主 PID——同一个进程，两套 PID 视图。

第四步：清理

# 退出容器 shell 后
sudo umount -R /tmp/minic/rootfs 2>/dev/null || true
sudo rm -rf /tmp/minic

umount -R 是保险：如果脚本中途失败，rootfs 里可能残留 proc/sys/tmpfs 挂载。清理前先 mount | grep /tmp/minic 确认。

5.1.5 限制：把「能用多少」交给 cgroups

最小容器已经能隔离视图，但没有限额。宿主上随便一个 yes 就能把 CPU 吃满。给进程加限额的标准做法是把它放进一个 cgroup v2 的叶子节点，然后写控制器文件。

不写 cgroup 文件也能先看到映射关系：systemd-run 会把 MemoryMax、CPUQuota 翻译成 cgroup 属性。

# 需要 root；起一个受限的 scope，观察它生成的 cgroup 文件
sudo systemd-run --scope --unit=demo-limits \
    -p MemoryMax=64M -p CPUQuota=25% -p TasksMax=32 \
    sleep 300

# 另一个终端：看 systemd 属性与内核文件
systemctl show demo-limits -p MemoryMax -p CPUQuotaPerSecUSec -p TasksMax
cat /sys/fs/cgroup/system.slice/demo-limits.scope/memory.max
cat /sys/fs/cgroup/system.slice/demo-limits.scope/cpu.max
cat /sys/fs/cgroup/system.slice/demo-limits.scope/pids.max

# 清理
sudo systemctl stop demo-limits

预期输出里，memory.max 是 67108864（64 MiB 的字节数），cpu.max 是 25000 100000（每 100 ms 周期最多用 25 ms CPU），pids.max 是 32。这三个文件就是 5.3 的主角；Docker 的 --memory、--cpus、--pids-limit 最终都落到同样的位置，只是路径变成 docker-<id>.scope 或 docker/<id>。

5.1.6 镜像：配置 + 层，而不是一个 rootfs 压缩包

容器启动时需要两样东西：一个解开的 rootfs，一份运行时配置（命令、环境变量、工作目录、用户）。镜像把这两样打包在一起，并额外记录「这些文件是怎么一层层叠出来的」。

以 Docker 镜像为例，它由三部分组成：

docker image inspect 能看到 config，docker save 能把整个镜像导出成 tar。后者是理解「层」的最快方式：

# 不需要 root（当前用户在 docker 组）
docker pull busybox:latest
docker image inspect busybox --format '{{json .RootFS.Layers}}' | python3 -m json.tool
docker save busybox -o /tmp/busybox.tar
tar -tf /tmp/busybox.tar | head -20

RootFS.Layers 是一个 SHA256 列表，每个元素对应一个层 tar。docker save 的输出布局随 Docker 版本与镜像存储驱动而变：经典布局是 manifest.json + <config>.json + <layer-id>/layer.tar；启用 containerd 镜像存储后是 OCI 布局（oci-layout、index.json、blobs/sha256/...）。两种布局表达的是同一件事，只是打包格式不同。

镜像分层带来两个直接后果：

1. 复用：ubuntu:24.04 与 nginx:latest 若共享基础层，磁盘上只存一份；docker pull 只下载缺少的层。
2. 写时复制：容器启动时不会复制整个 rootfs，而是把镜像层作为只读 lower，再加一个空的可写 upper。第一次修改某个文件才触发 copy-up（5.4 详述）。

容器层到底落在哪个目录

把「镜像只读、容器可写」这句话落到磁盘上，只需要三条命令：看驱动、写文件、看差异。

# 不需要 root（用户在 docker 组）
docker run -d --name fsdemo busybox sleep 1000
docker inspect fsdemo --format '{{.GraphDriver.Name}}'
# overlay2
docker inspect fsdemo --format '{{json .GraphDriver.Data}}' | python3 -m json.tool

# 在容器里写一个文件，再到宿主上看它落在哪
docker exec fsdemo sh -c 'echo hello > /newfile'
docker diff fsdemo
# A /newfile

# 需要 root：查看 overlay2 的可写层
sudo ls -l /var/lib/docker/overlay2/*/diff/newfile

GraphDriver.Data 会给出四个路径：LowerDir（冒号分隔的只读层）、UpperDir（可写层）、WorkDir、MergedDir（挂载点）。四者正好对应 5.4 的 lowerdir/upperdir/workdir/merged。docker diff 的 A 表示 added、C 表示 changed、D 表示 deleted；删除在 overlayfs 里并不是真的删 lower，而是写一个 whiteout，5.4.5 会验证。

注意：Docker 25 以后若启用了 containerd 镜像存储（docker info 里 Storage Driver: overlayfs 且 driver-type: io.containerd.snapshotter.v1），GraphDriver 可能为空，对应的目录在 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/ 下。机制相同，只是记账的人从 dockerd 换成了 containerd。

清理：

docker rm -f fsdemo

5.1.7 安全边界：容器里的 root 是谁

默认配置下（未启用 user namespace），容器里的 uid=0 就是宿主上的 uid=0。内核只做了一层能力检查：容器进程的 capabilities 被裁剪过，因此「是 root 但不能 mount、不能 mknod、不能改宿主时间」。一旦你给它 --privileged，这层裁剪被整体取消。

比 --privileged 小的做法有很多，关键是按需求给最小集合：

验证 capabilities 的最短命令：

# 默认容器：CapEff 是 14 个默认能力的位图
docker run --rm busybox grep '^Cap' /proc/self/status

# 只留一个能力
docker run --rm --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
    busybox grep '^CapEff' /proc/self/status

# 在宿主上解码位图（需要 libcap2-bin）
capsh --decode=00000000a80425fb

CapEff 是十六进制位图。默认 Docker 容器的值是 00000000a80425fb，对应 CHOWN DAC_OVERRIDE FOWNER FSETID KILL SETGID SETUID SETPCAP NET_BIND_SERVICE NET_RAW SYS_CHROOT MKNOD AUDIT_WRITE SETFCAP。把它清空后，容器里的 root 连 chown 都会失败——这正是「root 但无害」的样子。

user namespace 是另一条路：它把容器内的 uid 映射到宿主上的一个非特权 uid 区间。开启后，容器里的 uid=0 在宿主上显示为 100000，即使容器内进程拿到全部 capabilities，也只对那个 user namespace 有效。

# 不需要 root；把当前用户映射成新 user namespace 里的 root
unshare --user --map-root-user id
# uid=0(root) gid=0(root) groups=0(root)

# 看映射关系（在外层执行）
cat /proc/self/uid_map
#          0       1000          1

第一列是 namespace 内的 uid，第二列是宿主 uid，第三列是范围长度。0 1000 1 表示「容器里的 0 等于宿主的 1000，只映射一个」。多行映射需要 newuidmap/newgidmap 与 /etc/subuid、/etc/subgid 的配合，见 5.2.6。

除了 capabilities，还有两个开关会改变容器内 root 的「可提权性」，它们都能在 /proc/self/status 里直接读到：

# 默认：seccomp 处于 filter 模式（Seccomp: 2），no_new_privs 未开
docker run --rm busybox grep -E '^(Seccomp|NoNewPrivs)' /proc/self/status

# 打开 no_new_privs，并关掉 seccomp
docker run --rm --security-opt no-new-privileges \
    --security-opt seccomp=unconfined \
    busybox grep -E '^(Seccomp|NoNewPrivs)' /proc/self/status
# Seccomp:        0
# NoNewPrivs:     1

NoNewPrivs: 1 表示 execve 时不再获得任何新特权：setuid 位、文件 capabilities 全部失效。它防的是「容器里有个 setuid 的 sudo，被普通用户拿来提权到容器 root」这类路径。Seccomp: 2 表示已装载 BPF 过滤器；0 是完全不过滤。两者与 capabilities 是三套独立机制，任何一套缺失都不等于逃逸，但三套同时缺失就把内核攻击面完整暴露给容器。

5.1.8 一次 docker run 在内核里做了什么

把前面几节串起来。docker run 在用户看来是一条命令，在系统里是「守护进程 → 容器运行时 → 一组系统调用」的链式调用：

docker CLI
  │  POST /containers/create（REST，unix socket）
  ▼
dockerd ──gRPC──▶ containerd ──▶ containerd-shim-runc-v2
                                        │
                                        │ fork/exec
                                        ▼
                                      runc create
                                        ├─ clone(CLONE_NEWNS|NEWPID|NEWNET|NEWUTS|NEWIPC|NEWCGROUP)
                                        ├─ mount overlay：lower=镜像层, upper=容器可写层, work
                                        ├─ pivot_root + mount /proc /sys /dev
                                        ├─ 写 cgroup：cpu.max / memory.max / pids.max
                                        ├─ capset + seccomp + prctl(PR_SET_NO_NEW_PRIVS)
                                        └─ execve(entrypoint)  ← 容器 PID 1
                                        │
                                        ▼
                                      runc start（通过 exec fifo 放行）
                                        │
                                        ▼
                                      shim 常驻：持有 stdio、回收僵尸、转发信号

这张图解释了一个常被问的问题：为什么重启 dockerd 不会杀掉容器。容器的父进程不是 dockerd，而是 containerd-shim-runc-v2；shim 被 init 收养，dockerd/containerd 重启只是换了控制面，数据面（容器进程与 shim）不受影响。图里每一步对应的章节：

5.1.9 clone flags、/proc/PID/ns 与三件套接口表

这一节把「容器 = 一组 clone 标志 + 一次换根 + 一组 cgroup 文件」落到可查的接口上。不展开每种 namespace 的语义（5.2 负责），只给三张排障时最常用的表：标志位对应哪个内核对象、哪些组合非法、/proc/PID/ns 怎么读。

标志位与共享对象

clone 的 flags 分两类：CLONE_NEW* 创建新 namespace，其余位决定子进程与父进程共享还是复制某个内核对象。后者同样影响容器行为——共享 fs_struct 的进程无法各自 pivot_root，共享 files_struct 的进程无法各自关闭容器的 fd。

CLONE_NEWTIME 的值落在 CSIGNAL（0x000000ff）的低位区间内，这是历史遗留：它复用了信号位中未使用的一位。因此在解析 flags 时不能用「低位就是信号」一概而论，必须按 CSIGNAL 掩码单独取。

合法性矩阵：哪些组合会 EINVAL

copy_process 在分配 task_struct 之前就检查标志组合，不合法直接返回 EINVAL。这些检查不是随意设的，每一条都对应一个语义矛盾：

这张表解释了一个常见疑问：为什么 docker run 的 init 进程不能用 CLONE_THREAD 创建？因为容器的 1 号进程必须是一个独立的线程组 leader，而不是宿主某个线程组里的线程。

/proc/PID/ns：把 namespace 变成可比较的 inode

每个进程的 /proc/PID/ns/ 下有八个符号链接。链接内容是 类型:[inode]，stat -L 得到的 (st_dev, st_ino) 才是 namespace 的身份：

比较两个进程是否在同一 namespace，不要比较链接字符串（inode 号可能复用），要比较 stat：

# 不需要 root；比较两个进程的 net namespace 身份
a=$(stat -Lc '%d:%i' /proc/1/ns/net)
b=$(stat -Lc '%d:%i' /proc/self/ns/net)
[ "$a" = "$b" ] && echo "same netns" || echo "different netns"

/proc/PID/ns/* 还能 open 成 fd，配合 setns 进入。内核对这个 fd 定义了四个 ioctl：NS_GET_USERNS（取所属 user ns）、NS_GET_PARENT（取父 ns）、NS_GET_NSTYPE（取类型）、NS_GET_OWNER_UID（取 owner uid）。容器运行时正是用这些接口判断「这个 fd 是不是 netns」以及「它属于哪个 user ns」，而不是靠路径字符串。

结构体：nsproxy 与 ns_common

task_struct 不直接持有八个 namespace 指针，而是持有一个 nsproxy：

注意 pid_ns_for_children 的命名：当前进程自己的 PID 编号由它出生时的 PID ns 决定，而它 fork 出的子进程用 pid_ns_for_children。这解释了为什么 unshare --pid 不加 --fork 时，当前 shell 的 $$ 不变，只有下一次 fork 的子进程才进入新 ns。

每个 namespace 的公共头部是 struct ns_common：stashed（嵌入的 nsfs inode）、ops（proc_ns_operations）、inum（inode 号）、count。/proc/PID/ns/* 的链接内容就来自 inum，setns 则通过 ops->get 从 fd 反查 namespace 指针。

命令表

5.1.10 内核路径：从 clone 到 execve

这一节回答「一个容器进程从创建到跑起来，内核里依次经过哪些函数」。把这条路径记住，看到 docker run 卡住时就能判断卡在哪一段：clone、挂载、cgroup 还是 exec。

第一段：创建进程与 namespace

clone(2) / clone3(2)
  → kernel_clone()                       kernel/fork.c
      → copy_process()
          → copy_namespaces()            kernel/nsproxy.c
              → create_new_namespaces()
                  → copy_mnt_ns()        fs/namespace.c
                  → copy_utsname()       kernel/utsname.c
                  → copy_ipcs()          ipc/namespace.c
                  → copy_pid_ns()        kernel/pid_namespace.c
                  → copy_net_ns()        net/core/net_namespace.c
                  → copy_cgroup_ns()     kernel/cgroup/namespace.c
                  → copy_time_ns()       kernel/time/namespace.c
          → copy_fs() / copy_files() / copy_mm() / copy_sighand()
          → cgroup_can_fork()            kernel/cgroup/cgroup.c

copy_namespaces 的关键分支很短：如果 flags 里没有任何 CLONE_NEW*，它只增加 nsproxy 引用计数；否则调用 create_new_namespaces 逐个复制。下面这段代码说明了「没有新 namespace 时几乎零成本」：

/* kernel/nsproxy.c（Linux 6.8，节选） */
int copy_namespaces(unsigned long flags, struct task_struct *tsk)
{
    struct nsproxy *old_ns = tsk->nsproxy;
    struct user_namespace *user_ns = task_cred_xxx(tsk, user_ns);
    struct nsproxy *new_ns;

    if (likely(!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC |
                          CLONE_NEWPID | CLONE_NEWNET |
                          CLONE_NEWCGROUP | CLONE_NEWTIME)))) {
        if ((flags & CLONE_THREAD) && (current->nsproxy != tsk->nsproxy))
            get_nsproxy(tsk->nsproxy);
        return 0;
    }

    new_ns = create_new_namespaces(flags, tsk, user_ns, tsk->fs);
    if (IS_ERR(new_ns))
        return PTR_ERR(new_ns);

    tsk->nsproxy = new_ns;
    return 0;
}

create_new_namespaces 里的顺序有讲究：mount namespace 先复制，因为它要基于调用者的 fs_struct 找到根挂载；user namespace 最先解析，因为后面的 net/pid ns 创建都要在目标 user ns 里做权限检查。CLONE_NEWUSER 与 CLONE_FS 的 EINVAL 就是在这个阶段之前被 copy_process 拦下的。

cgroup_can_fork 是 CLONE_INTO_CGROUP 的落点：clone3 把目标 cgroup 的 fd 放在 struct clone_args.cgroup，内核在 fork 时直接把子进程的 css_set 指向该 cgroup，避免「先创建再迁移」的窗口。这个窗口在旧接口下是真实存在的：进程可能在被迁移前就跑完了初始化。

第二段：换根与挂载

mount("overlay", merged, "overlay", 0, "lowerdir=...,upperdir=...,workdir=...")
  → ovl_fill_super()                     fs/overlayfs/super.c
      → 解析 lowerdir/upperdir/workdir
      → ovl_get_root()                   构造 merged 的根 dentry

pivot_root(new_root, put_old)
  → do_pivot_root()                      fs/namespace.c
      → 检查 new_root 是挂载点、put_old 在 new_root 之下
      → attach_mnt() / detach_mnt()      交换挂载子树

pivot_root 的检查全部在 do_pivot_root 里完成，任何一条不满足都返回 EINVAL。它不是「改路径字符串」，而是操作 mount 树：把旧根挂载摘下来挂到 put_old，把新根挂载提升为 fs_struct->root。因此 pivot_root 之后旧根仍然存在（在 put_old 位置），必须再 umount 才真正不可达。

第三段：进入用户进程

execve("/bin/sh")
  → do_execveat_common()                 fs/exec.c
      → bprm_execve()
          → exec_binprm()
              → search_binary_handler()  按魔数找 loader
                  → load_elf_binary()    建立新地址空间、映射解释器
          → begin_new_exec()             切换 mm、关闭 close-on-exec fd

容器的「1 号进程」就是这一步 execve 之后的进程。它的 PID 在容器内是 1，在宿主上是另一个数；它的父进程是 shim 或 runc，取决于运行时是否用了 --pid=host、是否 double-fork。execve 成功后，copy_process 阶段创建的 task_struct 仍在，只是地址空间、fd 表、信号处理都换成了新程序的状态。

把四段串起来

五个可观测点

把这条路径变成排障手段，只需要在每一段找一个可读的证据：

这五条按顺序读，能把「容器起不来」压缩到某一段：进程在但 ns 不对是运行时配置问题；ns 对但 cgroup 在根是限额没写；cgroup 对但根挂载是宿主是 pivot_root 失败；最后一段失败则是镜像本身缺文件。

5.1.11 两个实验：flags 合法性 与 三件套合体

实验一：验证 copy_process 的 EINVAL 检查

这段程序故意构造五种非法组合，确认内核在创建进程之前就拒绝。它不需要 root：合法性检查发生在权限检查之前。

/* clonecheck.c — 验证 clone flags 的合法性检查；编译：cc -std=c17 -D_GNU_SOURCE -O2 -Wall -Wextra -Werror clonecheck.c -o clonecheck */
#include <errno.h>
#include <sched.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define STACK_SIZE (1 << 20)

static int child(void *arg)
{
    (void)arg;
    return 0;
}

int main(void)
{
    static const struct {
        const char *name;
        int flags;
    } cases[] = {
        { "NEWNS|FS",          CLONE_NEWNS | CLONE_FS | SIGCHLD },
        { "NEWUSER|FS",        CLONE_NEWUSER | CLONE_FS | SIGCHLD },
        { "THREAD 无 SIGHAND",  CLONE_THREAD | CLONE_VM | SIGCHLD },
        { "SIGHAND 无 VM",      CLONE_SIGHAND | SIGCHLD },
        { "SIGHAND|NEWPID",     CLONE_SIGHAND | CLONE_VM | CLONE_NEWPID | SIGCHLD },
    };
    char *stack = malloc(STACK_SIZE);
    if (stack == NULL) {
        perror("malloc");
        return EXIT_FAILURE;
    }

    for (size_t i = 0; i < sizeof(cases) / sizeof(cases[0]); i++) {
        errno = 0;
        pid_t pid = clone(child, stack + STACK_SIZE, cases[i].flags, NULL);
        if (pid == -1)
            printf("%-18s -> -1 errno=%d (%s)\n", cases[i].name, errno, strerror(errno));
        else
            printf("%-18s -> pid=%d（不应发生）\n", cases[i].name, (int)pid);
    }

    free(stack);
    return EXIT_SUCCESS;
}

预期输出：

NEWNS|FS           -> -1 errno=22 (Invalid argument)
NEWUSER|FS         -> -1 errno=22 (Invalid argument)
THREAD 无 SIGHAND   -> -1 errno=22 (Invalid argument)
SIGHAND 无 VM       -> -1 errno=22 (Invalid argument)
SIGHAND|NEWPID      -> -1 errno=22 (Invalid argument)

如果某一行返回了 pid，说明该内核版本的检查顺序或规则变了——这本身就是有价值的版本差异证据。注意不要在返回 pid 的分支里 waitpid：这些子进程共享父进程的栈，行为未定义，程序应立即退出。

实验二：三件套合体——隔离 + 限额 + 换根视角

这个实验用 unshare 造出 PID/mount/UTS 隔离，再把容器 init 的宿主 PID 写进 cgroup v2 叶子，观察限额是否真的作用到容器内进程。它不换根（rootfs 留给 5.4），但已经能验证「namespace 管看得见、cgroup 管用多少」是两条独立的线。

#!/usr/bin/env bash
# assemble.sh — 需要 root；把一个 unshare 容器放进 cgroup 并验证
set -euo pipefail
CG=/sys/fs/cgroup/assemble
PID=""

cleanup() {
    [ -n "$PID" ] && kill "$PID" 2>/dev/null || true
    sleep 0.2
    for p in "$CG/box" "$CG"; do
        [ -d "$p" ] && xargs -r kill < "$p/cgroup.procs" 2>/dev/null || true
    done
    sleep 0.2
    rmdir "$CG/box" "$CG" 2>/dev/null || true
}
trap cleanup EXIT

# 1. 造一个带 PID/mount/UTS 隔离的容器 init；--mount-proc 让容器内有独立 /proc
unshare --pid --fork --mount-proc --uts \
    sh -c 'hostname box; exec sh -c "while :; do :; done"' &
sleep 0.3
PID=$(pgrep -P "$!" | head -1)
[ -n "$PID" ] || { echo "找不到容器 init"; exit 1; }

# 2. 建 cgroup 并启用控制器
mkdir -p "$CG"
echo "+cpu +memory +pids" > /sys/fs/cgroup/cgroup.subtree_control 2>/dev/null || true
echo "+cpu +memory +pids" > "$CG/cgroup.subtree_control"
mkdir -p "$CG/box"

# 3. 写限额，把容器 init 迁进去（写任意线程 TID 都会迁移整个线程组）
echo "25000 100000" > "$CG/box/cpu.max"
echo $((64 * 1024 * 1024)) > "$CG/box/memory.max"
echo 32 > "$CG/box/pids.max"
echo "$PID" > "$CG/box/cgroup.procs"

# 4. 从宿主验证：进程确实在 cgroup 里，且限额文件生效
cat "/proc/$PID/cgroup"          # 0::/assemble/box
cat "$CG/box/cpu.max"            # 25000 100000
sleep 3
grep -E 'nr_periods|nr_throttled' "$CG/box/cpu.stat"

# 5. 从容器视角验证：hostname 与进程树都是隔离的
nsenter -t "$PID" -p -m -u -- hostname                 # box
nsenter -t "$PID" -p -m -u -- ps -o pid,ppid,comm      # 只有 1 号与 ps

预期输出：

0::/assemble/box
25000 100000
nr_periods 30
nr_throttled 29
box
    PID   PPID COMMAND
      1      0 sh
     12      1 ps

三行证据分别对应三件套：/proc/$PID/cgroup 证明进程被 cgroup 记账；nr_throttled 证明 cpu.max 对容器内的死循环生效；hostname 与 ps 证明 UTS/PID namespace 独立。注意 nsenter -p 进入 PID ns 后，ps 读的是容器自己的 /proc（--mount-proc 挂的那份），所以只看到两个进程。

如果把第 3 步的 echo "$PID" > cgroup.procs 删掉，第 4 步的 nr_throttled 会一直是 0——这就是「namespace 不等于限额」的直接反例。

5.1.12 OCI 配置：三件套在 config.json 里的字段

docker run 的参数最终被翻译成一份 JSON。OCI runtime-spec 规定的是这份 JSON 的字段与生命周期，不规定实现：runc、crun、youki 读同一份 config.json，做同一组系统调用。一个 bundle 只有两样东西：

bundle/  ├── config.json   ← 运行时读的全部配置（本节的表）
         └── rootfs/       ← 解开的根文件系统（overlay 层由运行时另建）

表里三处单位容易错：memory.limit 是字节，cpu.quota/cpu.period 是微秒，pids.limit 是任务数（线程也计）。它们与 5.3 的 memory.max、cpu.max、pids.max 一一对应；cpu.max 文件把 quota 与 period 写在同一行，JSON 里则是两个字段。

生命周期只有四步，每一步都能在 state.json 里看到：

state.json 的字段是 ociVersion、id、status、pid、bundle、annotations；pid 是宿主视角的 init PID，不是容器内的 1。hooks 的顺序也由 spec 固定，且执行位置不同：createRuntime 在运行时的 mount namespace 里、pivot_root 之前；createContainer 与 startContainer 在容器 namespace 里；poststart 在用户进程启动后、仍在运行时 namespace；poststop 在删除后。prestart 是 1.0.2 之前的旧名，等价于 createRuntime，新配置不应再写。

内核路径：CLONE_INTO_CGROUP 把「入组」提前到 fork

cgroupsPath 有两条实现路径：先 clone 再写 cgroup.procs（传统），或 clone3 时带 CLONE_INTO_CGROUP（Linux 5.7+，仅 cgroup v2）。后者把子进程的 css_set 在 copy_process 阶段就指向目标 cgroup，消除了「已创建、未入组」的记账窗口。

/* kernel/cgroup/cgroup.c（Linux 6.8，节选） */
static int cgroup_css_set_fork(struct kernel_clone_args *kargs)
{
    ...
    f = fget_raw(kargs->cgroup);
    if (!f) { ret = -EBADF; goto err; }
    sb = f->f_path.dentry->d_sb;
    dst_cgrp = cgroup_get_from_file(f);
    if (IS_ERR(dst_cgrp)) { ret = PTR_ERR(dst_cgrp); goto err; }
    if (cgroup_is_dead(dst_cgrp)) { ret = -ENODEV; goto err; }

    ret = cgroup_may_write(dst_cgrp, sb);
    if (ret) goto err;
    ret = cgroup_attach_permissions(cset->dfl_cgrp, dst_cgrp, sb,
                                    !(kargs->flags & CLONE_THREAD),
                                    current->nsproxy->cgroup_ns);
    ...
}

四个检查决定了常见错误码：fd 必须是 cgroup v2 目录（O_RDONLY 或 O_PATH），不能是 cgroup.procs 文件，否则 EBADF；目录已死返回 ENODEV；没有写权限返回 EACCES；目标 cgroup 处于 domain invalid 状态（cgroup.type 为 domain invalid）返回 EOPNOTSUPP。cgroup_can_fork 随后调用各控制器的 can_fork，pids 控制器在这里返回 -EAGAIN，所以 pids.max 打满时 fork 直接失败，而不是先成功再被踢出。

5.1.13 两个补充实验：最小 OCI bundle 与 pivot_root 的逃逸边界

实验一：不装 Docker，用 runc 跑一份手写 config.json

这个实验验证「OCI 配置就是三件套的声明式写法」：同一份 JSON，runc 执行后你能在 cgroup、/proc、挂载表里找到对应项。需要 root 与 cgroup v2（Ubuntu 24.04 默认）。

# 需要 root；准备 bundle
sudo apt-get install -y runc busybox-static
sudo mkdir -p /tmp/oci/rootfs/{bin,proc,dev,tmp}
sudo cp /bin/busybox /tmp/oci/rootfs/bin/
for a in sh id hostname ps sleep; do
    sudo ln -sf busybox "/tmp/oci/rootfs/bin/$a"
done

sudo tee /tmp/oci/config.json >/dev/null <<'JSON'
{
  "ociVersion": "1.2.0",
  "process": {
    "user": {"uid": 0, "gid": 0},
    "args": ["/bin/sh", "-c", "hostname; id; echo pid=$$; ps; sleep 600"],
    "env": ["PATH=/bin"],
    "cwd": "/",
    "capabilities": {
      "bounding": ["CAP_CHOWN", "CAP_KILL", "CAP_NET_BIND_SERVICE"],
      "effective": ["CAP_CHOWN", "CAP_KILL", "CAP_NET_BIND_SERVICE"], "permitted": ["CAP_CHOWN", "CAP_KILL", "CAP_NET_BIND_SERVICE"] },
    "rlimits": [{"type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024}],
    "noNewPrivileges": true
  },
  "root": {"path": "rootfs", "readonly": true},
  "hostname": "oci-demo",
  "mounts": [
    {"destination": "/proc", "type": "proc", "source": "proc", "options": ["nosuid", "noexec", "nodev"]},
    {"destination": "/dev", "type": "tmpfs", "source": "tmpfs",
     "options": ["nosuid", "strictatime", "mode=755", "size=65536k"]}
  ],
  "linux": {
    "namespaces": [{"type": "pid"}, {"type": "mount"}, {"type": "uts"},
                   {"type": "ipc"}, {"type": "network"}],
    "cgroupsPath": "oci-demo",
    "resources": {
      "memory": {"limit": 67108864},
      "cpu": {"quota": 25000, "period": 100000},
      "pids": {"limit": 32}
    }
  }
}
JSON

cd /tmp/oci
sudo runc run -d oci-demo          # -d：创建后立即返回
sudo runc list
sudo runc exec oci-demo ps -o pid,ppid,comm
cat /sys/fs/cgroup/oci-demo/memory.max
cat /sys/fs/cgroup/oci-demo/cpu.max
cat /sys/fs/cgroup/oci-demo/pids.max
sudo runc kill oci-demo KILL
sudo runc delete oci-demo

预期输出（PID、inode 随机器变化）：

ID         PID    STATUS    BUNDLE     CREATED
oci-demo   2417   running   /tmp/oci   2026-10-18T...
    PID   PPID COMMAND
      1      0 sh
     12      1 ps
67108864
25000 100000
32

三组证据：runc list 的 PID 是宿主 PID；runc exec ... ps 只看到两个进程（PID+mount namespace 生效）；memory.max/cpu.max/pids.max 与 JSON 的 resources 完全对应（cpu.max 把 quota/period 合成一行）；root.readonly=true 下在容器里 touch /x 应返回 Read-only file system——只读的是 rootfs，不是 /proc 等挂载。

如果把 linux.namespaces 里的 pid 删掉，ps 会看到宿主全部进程，而 hostname 仍是 oci-demo（UTS 还在）。这正好演示「namespace 是逐项声明的，不是容器开关」。

实验二：chroot 留下的宿主路径，pivot_root 摘掉旧根

这个实验验证 5.1.3 的结论：chroot 只改根指针，宿主根仍能通过 /proc/1/root 或未卸载的旧根到达；pivot_root 必须配合卸载旧根才算封死。需要 root 与 busybox-static。

# 准备 rootfs（可复用实验一的 /tmp/oci/rootfs）
J=/tmp/jaildemo
sudo rm -rf "$J"
sudo mkdir -p "$J"/{bin,proc,dev,tmp}
sudo cp /bin/busybox "$J/bin/"
for a in sh ls cat chroot; do sudo ln -sf busybox "$J/bin/$a"; done

# (a) 只有 chroot：/proc 仍是宿主的，/proc/1/root 直通宿主根
sudo mount -t proc proc "$J/proc"
sudo chroot "$J" /bin/sh -c 'cat /proc/1/root/etc/hostname; ls /proc/1/root | head -3'
# 输出宿主主机名与宿主根目录项
sudo umount "$J/proc"

/proc/1/root 是宿主 init 的根，chroot 不会改变它；只要 /proc 还是宿主那一份，容器里的进程就能顺着它读写宿主文件。这是 chroot 不能当安全边界的第一条证据。

# (b) pivot_root + 新 /proc + 摘掉旧根：/proc/1/root 只能回到容器根
sudo unshare --mount --fork --pid --uts sh -c '
  mount --make-rprivate /
  mount --bind '"$J"' '"$J"'
  mount -t proc proc '"$J"'/proc
  cd '"$J"'
  mkdir -p .oldroot
  pivot_root . .oldroot
  umount -l /.oldroot
  exec /bin/sh
'
# 容器内：
#   cat /proc/1/root/etc/hostname   → No such file or directory
#   ls /                            → bin dev proc tmp

新 /proc 让 /proc/1 变成容器 init 自己，/proc/1/root 只指向新根。若删掉 umount -l /.oldroot，容器里仍能 ls /.oldroot 看到宿主根，甚至 chroot /.oldroot /bin/sh 回到宿主——pivot_root 只是把旧根挪到 .oldroot，不卸载就不算封死。只读镜像 + 去掉 CAP_SYS_CHROOT，才是运行时的完整做法。

5.1.14 本章陷阱清单

下面 14 条是「把三件套拼起来」时最容易踩的边界，按现象、原因、修复排列。与各节末尾的 errata 不重复：这里讲的是组合之后才出现的问题。

5.1.15 本章出口检查

母本对应

下一站：5.2 namespace 深入 把七种 namespace 逐个拆开：clone/unshare/setns 的差别、/proc/PID/ns 的 inode、PID 1 的信号语义，以及 nsenter 排障。