容器 20：rootless 和容器内非 root 有什么不同
在05，内侧 root 被映射为外侧 UID 1001，说明“程序显示 UID 0”不足以推出宿主特权。另一种常被混写的配置是 Dockerfile USER 65532：它指定应用在容器内的身份，并没有规定 daemon 本身用哪个宿主 UID 工作。rootless 模式则涉及 daemon 和容器进程的宿主权限前提，资源与网络能力也随委派和实现改变。
三个身份分别记账
先记录 daemon 宿主身份、容器外侧 UID 映射与应用内侧 UID，再问低端口绑定、设备访问、overlay/snapshotter、cgroup v2 控制器和网络转发在所选 rootless 实现中如何实现。不应把“daemon 非 root”和“应用 USER 非 root”合并成一项。rootless 不会凭空委派宿主 cgroup 子树，也不是应用任意设备访问的许可证。不同运行时和 Linux 版本对辅助工具、存储与网络的要求不同；适用范围必须限定到实测版本。
正常实验在专用 VM 用同一探针分别以 rootful daemon + USER 65532 与 rootless daemon + 相同应用 UID 启动，对照 daemon PID/UID、应用内外 UID/map、端口和 cgroup 可写项。边界例在没有资源委派时设置 CPU limit：配置请求也许被拒绝或不起作用，必须读 cgroup 实际内容及官方限制再解释，不能拿两次 id 输出当限额已经生效。入口给出清单，自含源码与 13 共用 Dockerfile。
本机 userns 可用，但无 rootless daemon、cgroup v2 委派和 runtime。05 的映射记录只证明 userns 的一部分；20 的 daemon/容器对照及端口、资源限制均 NOT_RUN。
| 现象 | 身份/对象 | 前提 |
|---|---|---|
| 应用 UID 65532 | Dockerfile USER 与运行时用户 | daemon 未必 rootless |
| daemon 宿主非 root | daemon PID、uid_map | 不推出 CPU 委派可用 |
| 端口绑定失败 | 端口、转发实现、权限 | 不只看应用 id |
练习
- 先预测把
USER 65532放入同一个 Dockerfile 后，宿主 daemon 身份会不会变化；在 VM 逐项读 daemon 与应用 UID/map。 - 预测 rootless 模式下设置
cpu.max一定生效吗；先确认父组控制器和委派，再对照所选实现的错误、运行时配置与实际计数。
上一篇：19：run 到 exec；下一篇：21：停止与日志。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 05：容器里的 root 究竟是谁
程序在内部打印 uid=0，并不意味着它在宿主初始 user namespace 中获得了宿主 root 的身份。前提是内核如何把内部 UID/GID 映射到外侧身份，目录所有权从哪一个 user namespace 解释，以及该操作的权限检查针对哪个对象。先把04 的路径/挂载视图与身份映射分开；rootfs 的路径变化不能自动改变用户映射。 UID 是映射关系，不是全局标签 /proc/<pid>/uid_map 的每行含“内部起始 UID、外部起始 UID、数量”，gid_map 同理。进入新的 user namespace 后，内部 root 可以对应外侧非特权 UID，具体权限由映射、文件系统、被检查的 namespace 及内核能力决定；映射不意味着访问所有外侧 root 拥有的目录。写 gid_map 通常还涉及 /proc/.../setgroups 的限制，不能盲目照搬 uid_map 的写法。把进程设为容器内普通 USER 与以非特权身份运行 daemon 并使用 user namespace（rootless）是两个不同维度。 读映射时...
2026-10-01
容器 12：镜像拉取是下载还是解包
本地已知镜像的index、manifest 与 blob，接下来问另一台机器如何得到相同字节。Distribution Specification 约定 registry API；它不等于 Linux 的 mount、容器进程的 exec，也不保证客户端已把层成功解压成可运行的 rootfs。 引用解析和内容获取分开 客户端把名字/tag 交给 registry，商议清单媒体类型，读取 manifest 后根据 descriptor 的 digest 与 size 请求 config 和 layer blob。digest 绑定字节，tag 可重新指向另一 manifest；“我拉到了 tag”不能证明和上一次拉到的内容相同。Blob 下载成功仍需校验摘要、解压层、建立本机快照才能供运行时使用。认证失败应定位到 HTTP 挑战、凭据与仓库权限，缺失 blob 则应定位对应 digest 和 HTTP 返回，而非笼统说“网络不通”。不要将镜像 registry 的身份验证和镜像签名混为一谈。 引用如何落到确定的 manifest OCI Distribution Specifica...
2026-06-20
CRD 与 Operator 模式——扩展 Kubernetes 的标准路径
Kubernetes 的核心设计哲学之一是可扩展性。API Server 内置的资源类型——Pod、Deployment、Service——只能覆盖通用计算模型，但现实中的应用远不止于此：数据库集群有自己的主从切换逻辑，消息队列有 topic 副本的分配策略，机器学习训练任务有 GPU 亲和性和检查点管理。CustomResourceDefinition（CRD）和 Operator 模式正是 Kubernetes 给出的扩展机制：让用户把领域知识编码进集群本身，而不是写在外部脚本或运维手册里。 CRD 的核心能力是向 API Server 注册新的 Group/Version/Kind（GVK）。注册完成后，kubectl get myapp 和 kubectl get pod 在 API 层面对等——同样走 REST 接口，同样存储到 etcd，同样支持 watch、label selector 和 RBAC 授权。Operator 在 CRD 之上再加一层：部署一个 Controller，持续监听自定义资源的变化，把用户声明的期望状态翻译成若干内置 Kubernetes 资...
2026-10-01
容器 E06：Wasm 模块不是 Linux 容器进程
OCI 的制品分发与执行合约是不同层。10 的 descriptor/manifest可以组织非传统 rootfs 制品，但一个 Wasm 模块如何运行，依赖选定 Wasm runtime、WASI 版本与宿主接口，而不是把 .wasm 文件放进 OCI layer 就自动变成 Linux ELF 进程。 对比的是同一功能，不是同一执行模型 Linux probe-app 用 Python HTTP server，经内核的 socket 系统调用处理请求；WASI 提供的系统接口与实现能力随版本、runtime 而变。若要比较相同功能，必须选定能提供所需网络和文件能力的具体实现，明确编译目标和运行参数，再通过 OCI 制品把模块与运行配置交给支持该制品的 runtime；传统 runc 不会因此执行 Wasm 模块。正例在独立 VM 选定一个明确支持该 WASI 功能的 runtime，实现与 probe-app 可对照的简单响应；反例去掉相应 WASI 能力或选用不支持的 runtime，记录制品能被下载但无法执行的错误。版本与具体源码调用路径须按安装后实际情况核查。...
2026-10-01
容器 32：从错误症状回到失败层
启动失败的提示往往出现在最高一层：CLI、Pod condition 或 HTTP 超时。修复需要逆向定位首个出错环节。沿10 的 digest、17 的 bundle、24 的网络对象与28 的就绪状态逐层判断，先记录假设，再以明确证据排除。 四种会混成一个“起不来”的情况 第一，镜像无法解析或 layer blob 缺失：还没有完整根文件，查看拉取响应与 digest。第二，平台不匹配：索引没该平台或启动可执行文件时产生架构错误，核对节点架构与目标文件格式。第三，运行时配置或挂载权限被拒：先找 OCI bundle/config、宿主权限与 errno，不能怪应用网络。第四，进程已经运行但监听 127.0.0.1、readiness 返回 503 或 Service 后端未更新：先比较 PID、目标地址、探针与真实请求。每类都要设计一条可被反例推翻的排除证据，不能只列故障关键词。 在专用实验 VM 以相同 probe-app 分别制造四类受控故障：错误镜像摘要/缺 blob、错误架构、只读写入目录、错误监听地址或 readiness 延迟；同一时刻只改一个变量，并为每次保留镜...
2026-10-01
容器 08：namespace 之外还需要什么权限边界
05 的 UID 映射说明谁拥有某个身份，06说明资源预算。但“内部是 root、有独立 hostname”不等于可信边界：进程发起系统调用时仍会进入宿主内核。允许执行什么操作，还要逐项解释 capability、seccomp、`no_new_privs` 与实际启用的 LSM。 把拒绝归还给负责的层 capability 将特权操作拆成较细粒度的授权，内核权限检查会结合针对的 user namespace。CAP_SYS_ADMIN 在新 user namespace 中的有效位不等于初始 namespace 的万能通行证，挂载还受文件系统与上层策略约束。seccomp BPF 按系统调用及可检查参数限制调用面，不识别“这个路径属于秘密”这样的完整安全语义；内核文档明确说过滤器本身不是 sandbox。no_new_privs 禁止 exec 后取得比此前更多的特权，不能据此说所有操作都会拒绝。SELinux、AppArmor 等 LSM 是否启用、具体 profile 如何拒绝，要按专用 VM 的配置和审计日志核查，不能套用另一台机器的默认值。 从系统调用走到目标对象 进程...