文章指出，用户命名空间的设计前提是“特权不外溢”：非特权用户可以创建命名空间，在内部表现为 root，用于支撑 rootless 容器与无特权构建。问题在于这一前提依赖内核各处检查的一致性，文件 capability 是其中一个薄弱点。

风险点在于二进制文件上以扩展属性保存的 capability 与命名空间的映射关系交互复杂。当命名空间内的进程能够对被外部进程使用的文件设置或复用 capability 时，就可能出现“内部动作、外部生效”的提权路径。Josef Bacik 提交的小型补丁系列正是针对这类情形，修正设置文件 capability 时的命名空间判定。

LWN 提醒，这类问题的修复通常需要同时兼顾容器工具链的既有行为，避免破坏 rootless Podman、unshare 类沙箱等依赖命名空间的用法。对企业 IT 与安全团队而言，直接可执行的结论是：在不需要用户命名空间的服务器上保持 kernel.unprivileged_userns_clone 一类的开关关闭，把命名空间的启用范围限制在容器与构建节点，并及时跟进包含该修复的内核版本。

来源：LWN，原文。