OCI/runc 系统路径约束如何防止重新安装此类路径？
How does OCI/runc system path constraining work to prevent remounting such paths?
我的问题的背景是我的 Linux-kernel Namespaces discovery Go package lxkns 的一组测试用例，我在其中创建了一个新的子用户命名空间以及一个测试容器内的新的子 PID 命名空间。然后我需要重新挂载/proc，否则我会看到错误的进程信息并且无法查找正确的进程相关信息，例如新的子用户+PID 命名空间中的测试进程的命名空间（无需诉诸游击战术）。
测试 harness/test 设置基本上是这样的，没有 --privileged 就失败了（我正在简化所有大写并关闭 seccomp 和 apparmor 以切入真正的肉）：
docker run -it --rm --name closedboxx --cap-add ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined busybox unshare -Umpfr mount -t proc /proc proc
mount: permission denied (are you root?)
当然，阻力最小且最不美观的途径是使用 --privileged，这将完成工作，因为这是一个一次性测试容器（也许有美观完全没有它）。
最近，我注意到 Docker 的 --security-opt systempaths=unconfined，它（afaik）在生成的 OCI/runc 容器规范中转换为空 readonlyPaths。下面的Docker运行命令按需成功，它只是returns在示例中默默地执行，所以正确执行：
docker run -it --rm --name closedboxx --cap-add ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined --security-opt systempaths=unconfined busybox unshare -Umpfr mount -t proc /proc proc
如果设置失败，当 运行ning 没有 --privilege 且没有 --security-opt systempaths=unconfined 时，容器内的子用户和 PID 命名空间内的挂载如下所示：
docker run -it --rm --name closedboxx --cap-add ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined busybox unshare -Umpfr cat /proc/1/mountinfo
693 678 0:46 / / rw,relatime - overlay overlay rw,lowerdir=/var/lib/docker/overlay2/l/AOY3ZSL2FQEO77CCDBKDOPEK7M:/var/lib/docker/overlay2/l/VNX7PING7ZLTIPXRDFSBMIOKKU,upperdir=/var/lib/docker/overlay2/60e8ad10362e49b621d2f3d603845ee24bda62d6d77de96a37ea0001c8454546/diff,workdir=/var/lib/docker/overlay2/60e8ad10362e49b621d2f3d603845ee24bda62d6d77de96a37ea0001c8454546/work,xino=off
694 693 0:50 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
695 694 0:50 /bus /proc/bus ro,relatime - proc proc rw
696 694 0:50 /fs /proc/fs ro,relatime - proc proc rw
697 694 0:50 /irq /proc/irq ro,relatime - proc proc rw
698 694 0:50 /sys /proc/sys ro,relatime - proc proc rw
699 694 0:50 /sysrq-trigger /proc/sysrq-trigger ro,relatime - proc proc rw
700 694 0:51 /null /proc/kcore rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
701 694 0:51 /null /proc/keys rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
702 694 0:51 /null /proc/latency_stats rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
703 694 0:51 /null /proc/timer_list rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
704 694 0:51 /null /proc/sched_debug rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
705 694 0:56 / /proc/scsi ro,relatime - tmpfs tmpfs ro
706 693 0:51 / /dev rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
707 706 0:52 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
708 706 0:49 / /dev/mqueue rw,nosuid,nodev,noexec,relatime - mqueue mqueue rw
709 706 0:55 / /dev/shm rw,nosuid,nodev,noexec,relatime - tmpfs shm rw,size=65536k
710 706 0:52 /0 /dev/console rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
711 693 0:53 / /sys ro,nosuid,nodev,noexec,relatime - sysfs sysfs ro
712 711 0:54 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,mode=755
713 712 0:28 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/systemd ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,xattr,name=systemd
714 712 0:31 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/cpuset ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuset
715 712 0:32 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/net_cls,net_prio ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,net_cls,net_prio
716 712 0:33 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,memory
717 712 0:34 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/perf_event ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,perf_event
718 712 0:35 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/devices ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,devices
719 712 0:36 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/blkio ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,blkio
720 712 0:37 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/pids ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,pids
721 712 0:38 / /sys/fs/cgroup/rdma ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,rdma
722 712 0:39 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/freezer ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer
723 712 0:40 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpu,cpuacct
724 711 0:57 / /sys/firmware ro,relatime - tmpfs tmpfs ro
725 693 8:2 /var/lib/docker/containers/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0/resolv.conf /etc/resolv.conf rw,relatime - ext4 /dev/sda2 rw,stripe=256
944 693 8:2 /var/lib/docker/containers/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0/hostname /etc/hostname rw,relatime - ext4 /dev/sda2 rw,stripe=256
1352 693 8:2 /var/lib/docker/containers/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0/hosts /etc/hosts rw,relatime - ext4 /dev/sda2 rw,stripe=256
- 究竟是什么机制阻止了
/proc 上 procfs 的新挂载？
- 是什么阻止我卸载
/proc/kcore 等？
更多的挖掘发现了这个 answer to "About mounting and unmounting inherited mounts inside a newly-created mount namespace"，它指向了正确的方向，但需要额外的解释（尤其是基于一个误导性的段落，关于挂载命名空间是从 Michael Kerrisk 修复的手册页中分层的前段时间）。
我们的起点是 runc 设置（测试）容器时，为了屏蔽系统路径，尤其是在容器的未来 /proc 树中，它创建了一组新的挂载来屏蔽掉使用 /dev/null 的单个文件或使用 tmpfs 的子目录。这导致 procfs 被安装在 /proc 上，以及更多的子安装。
现在测试容器启动，在某个时候进程取消共享到新的用户命名空间。请记住，这个新用户命名空间（再次）属于 UID 为 0 的（真实）root 用户，因为默认 Docker 安装不会在新用户命名空间中启用 运行 容器。
接下来，测试进程也取消共享到一个新的挂载命名空间，所以这个新的挂载命名空间属于新创建的用户命名空间，但不属于初始用户命名空间。根据 mount_namespaces(7) 中的“挂载名称空间限制”部分：
If the new namespace and the namespace from which the mount point list was copied are owned by different user namespaces, then the new mount namespace is considered less privileged.
请注意这里的标准是：“donor”挂载命名空间和新的挂载命名空间有不同个用户命名空间；他们是否拥有相同的所有者用户 (UID) 并不重要。
现在的重要线索是：
Mounts that come as a single unit from a more privileged mount namespace are locked together and may not be separated in a less privileged mount namespace. (The unshare(2) CLONE_NEWNS operation brings across all of the mounts from the original mount namespace as a single unit, and recursive mounts that propagate between mount namespaces propagate as a single unit.)
由于现在无法再将 /proc 挂载点与屏蔽子挂载分开，因此无法（重新）挂载 /proc（问题 1）。同样的道理，卸载 /proc/kcore 是不可能的，因为那样会允许 unmasking（问题 2）。
现在，当使用 --security-opt systempaths=unconfined 部署测试容器时，这会导致 单个 /proc 挂载，没有任何掩蔽子挂载。因此，根据上面引用的手册页规则，只有一个我们可以（重新）安装的安装，受制于 CAP_SYS_ADMIN 能力，包括安装（除了大量其他有趣的功能）。
请注意，可以在容器内卸载屏蔽的 /proc/ 路径，同时仍在原始（=初始）用户命名空间中并且拥有（不足为奇） ) CAP_SYS_ADMIN。 (b)lock 只在一个单独的用户命名空间中启动，因此一些项目努力在他们自己的新用户命名空间中部署容器（不幸的是，这对容器网络有影响）。
我的问题的背景是我的 Linux-kernel Namespaces discovery Go package lxkns 的一组测试用例，我在其中创建了一个新的子用户命名空间以及一个测试容器内的新的子 PID 命名空间。然后我需要重新挂载/proc，否则我会看到错误的进程信息并且无法查找正确的进程相关信息，例如新的子用户+PID 命名空间中的测试进程的命名空间（无需诉诸游击战术）。
测试 harness/test 设置基本上是这样的，没有 --privileged 就失败了（我正在简化所有大写并关闭 seccomp 和 apparmor 以切入真正的肉）：
docker run -it --rm --name closedboxx --cap-add ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined busybox unshare -Umpfr mount -t proc /proc proc
mount: permission denied (are you root?)
当然，阻力最小且最不美观的途径是使用 --privileged，这将完成工作，因为这是一个一次性测试容器（也许有美观完全没有它）。
最近，我注意到 Docker 的 --security-opt systempaths=unconfined，它（afaik）在生成的 OCI/runc 容器规范中转换为空 readonlyPaths。下面的Docker运行命令按需成功，它只是returns在示例中默默地执行，所以正确执行：
docker run -it --rm --name closedboxx --cap-add ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined --security-opt systempaths=unconfined busybox unshare -Umpfr mount -t proc /proc proc
如果设置失败，当 运行ning 没有 --privilege 且没有 --security-opt systempaths=unconfined 时，容器内的子用户和 PID 命名空间内的挂载如下所示：
docker run -it --rm --name closedboxx --cap-add ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined busybox unshare -Umpfr cat /proc/1/mountinfo
693 678 0:46 / / rw,relatime - overlay overlay rw,lowerdir=/var/lib/docker/overlay2/l/AOY3ZSL2FQEO77CCDBKDOPEK7M:/var/lib/docker/overlay2/l/VNX7PING7ZLTIPXRDFSBMIOKKU,upperdir=/var/lib/docker/overlay2/60e8ad10362e49b621d2f3d603845ee24bda62d6d77de96a37ea0001c8454546/diff,workdir=/var/lib/docker/overlay2/60e8ad10362e49b621d2f3d603845ee24bda62d6d77de96a37ea0001c8454546/work,xino=off
694 693 0:50 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
695 694 0:50 /bus /proc/bus ro,relatime - proc proc rw
696 694 0:50 /fs /proc/fs ro,relatime - proc proc rw
697 694 0:50 /irq /proc/irq ro,relatime - proc proc rw
698 694 0:50 /sys /proc/sys ro,relatime - proc proc rw
699 694 0:50 /sysrq-trigger /proc/sysrq-trigger ro,relatime - proc proc rw
700 694 0:51 /null /proc/kcore rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
701 694 0:51 /null /proc/keys rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
702 694 0:51 /null /proc/latency_stats rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
703 694 0:51 /null /proc/timer_list rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
704 694 0:51 /null /proc/sched_debug rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
705 694 0:56 / /proc/scsi ro,relatime - tmpfs tmpfs ro
706 693 0:51 / /dev rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755
707 706 0:52 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
708 706 0:49 / /dev/mqueue rw,nosuid,nodev,noexec,relatime - mqueue mqueue rw
709 706 0:55 / /dev/shm rw,nosuid,nodev,noexec,relatime - tmpfs shm rw,size=65536k
710 706 0:52 /0 /dev/console rw,nosuid,noexec,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
711 693 0:53 / /sys ro,nosuid,nodev,noexec,relatime - sysfs sysfs ro
712 711 0:54 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,mode=755
713 712 0:28 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/systemd ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,xattr,name=systemd
714 712 0:31 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/cpuset ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuset
715 712 0:32 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/net_cls,net_prio ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,net_cls,net_prio
716 712 0:33 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,memory
717 712 0:34 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/perf_event ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,perf_event
718 712 0:35 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/devices ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,devices
719 712 0:36 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/blkio ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,blkio
720 712 0:37 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/pids ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,pids
721 712 0:38 / /sys/fs/cgroup/rdma ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,rdma
722 712 0:39 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/freezer ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer
723 712 0:40 /docker/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0 /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpu,cpuacct
724 711 0:57 / /sys/firmware ro,relatime - tmpfs tmpfs ro
725 693 8:2 /var/lib/docker/containers/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0/resolv.conf /etc/resolv.conf rw,relatime - ext4 /dev/sda2 rw,stripe=256
944 693 8:2 /var/lib/docker/containers/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0/hostname /etc/hostname rw,relatime - ext4 /dev/sda2 rw,stripe=256
1352 693 8:2 /var/lib/docker/containers/eebfacfdc6e0e34c4e62d9f162bdd7c04b232ba2d1f5327eaf7e00011d0235c0/hosts /etc/hosts rw,relatime - ext4 /dev/sda2 rw,stripe=256
- 究竟是什么机制阻止了
/proc上procfs的新挂载？ - 是什么阻止我卸载
/proc/kcore等？
更多的挖掘发现了这个 answer to "About mounting and unmounting inherited mounts inside a newly-created mount namespace"，它指向了正确的方向，但需要额外的解释（尤其是基于一个误导性的段落，关于挂载命名空间是从 Michael Kerrisk 修复的手册页中分层的前段时间）。
我们的起点是 runc 设置（测试）容器时，为了屏蔽系统路径，尤其是在容器的未来 /proc 树中，它创建了一组新的挂载来屏蔽掉使用 /dev/null 的单个文件或使用 tmpfs 的子目录。这导致 procfs 被安装在 /proc 上，以及更多的子安装。
现在测试容器启动，在某个时候进程取消共享到新的用户命名空间。请记住，这个新用户命名空间（再次）属于 UID 为 0 的（真实）root 用户，因为默认 Docker 安装不会在新用户命名空间中启用 运行 容器。
接下来，测试进程也取消共享到一个新的挂载命名空间，所以这个新的挂载命名空间属于新创建的用户命名空间，但不属于初始用户命名空间。根据 mount_namespaces(7) 中的“挂载名称空间限制”部分：
If the new namespace and the namespace from which the mount point list was copied are owned by different user namespaces, then the new mount namespace is considered less privileged.
请注意这里的标准是：“donor”挂载命名空间和新的挂载命名空间有不同个用户命名空间；他们是否拥有相同的所有者用户 (UID) 并不重要。
现在的重要线索是：
Mounts that come as a single unit from a more privileged mount namespace are locked together and may not be separated in a less privileged mount namespace. (The unshare(2) CLONE_NEWNS operation brings across all of the mounts from the original mount namespace as a single unit, and recursive mounts that propagate between mount namespaces propagate as a single unit.)
由于现在无法再将 /proc 挂载点与屏蔽子挂载分开，因此无法（重新）挂载 /proc（问题 1）。同样的道理，卸载 /proc/kcore 是不可能的，因为那样会允许 unmasking（问题 2）。
现在，当使用 --security-opt systempaths=unconfined 部署测试容器时，这会导致 单个 /proc 挂载，没有任何掩蔽子挂载。因此，根据上面引用的手册页规则，只有一个我们可以（重新）安装的安装，受制于 CAP_SYS_ADMIN 能力，包括安装（除了大量其他有趣的功能）。
请注意，可以在容器内卸载屏蔽的 /proc/ 路径，同时仍在原始（=初始）用户命名空间中并且拥有（不足为奇） ) CAP_SYS_ADMIN。 (b)lock 只在一个单独的用户命名空间中启动，因此一些项目努力在他们自己的新用户命名空间中部署容器（不幸的是，这对容器网络有影响）。