直接用 setuid 做进程隔离不安全，因其仅改有效 UID 而不隔离内核资源视图，无法防止 /proc 遍历、fd 访问、mount 泄露、group 恢复、资源耗尽等问题；必须配合 unshare 创建 user 等命名空间并正确排序，且需补足 cgroup、seccomp、capability 三方面限制。
为什么 直接用 setuid 做进程隔离不安全
因为 setuid 只改变有效用户 ID，不隔离内核视角下的资源视图。一旦进程被利用（比如通过 ptrace 或内存泄漏），攻击者仍能遍历 /proc、访问同主机其他进程的文件描述符、甚至挂载新文件系统——它根本没切断命名空间关联。
常见错误现象：sudo -u nobody /usr/bin/python3 -c "import os; print(os.listdir('/proc'))" 依然能看到所有进程 PID 目录；ls /proc/1/fd 在未隔离时可能成功读取 init 进程的打开文件。
- 仅靠
setuid+chroot无法防止 mount namespace 泄露（例如攻击者执行mount --bind /etc /tmp/etc后逃逸） - glibc 的
initgroups()调用可能意外恢复 supplementary groups，导致权限扩大 - 没有 cgroup 限制时，恶意进程可耗尽内存或 fork 炸弹拖垮整机
unshare + chroot 组合的关键参数顺序
必须先用 unshare 创建新命名空间，再 chroot 切换根目录。反过来会失败：子进程在旧 mount namespace 中无法真正隐藏宿主文件系统。
典型安全组合命令：
unshare --user --pid --ipc --uts --net --mount --fork --root=/var/chroot/myapp --set-groups=deny --map-root-user /bin/sh -c 'chroot /var/chroot/myapp /bin/sh'注意点：
-
--map-root-user是必须的，否则新 user namespace 中 UID 0 不映射到宿主任何 UID，导致chroot后连ls都因权限拒绝失败 -
--set-groups=deny阻止子进程调用setgroups(2)，否则可能重新获得额外 group 权限 -
--mount必须配合--fork，否则后续chroot会因共享 mount namespace 而暴露原根目录
为什么 clone() 的 CLONE_NEWUSER 必须第一个启用
Linux 内核强制要求：如果要创建 user namespace，它必须是第一个被启用的 namespace。否则 clone() 或 unshare() 会返回 EINVAL 错误。
错误示例（shell 中不可见，但 C 程序中常见）：
unshare --pid --user # 失败：EINVAL正确顺序：
unshare --user --pid --mount --net # 成功原因在于：user namespace 是权限降级的锚点，其他 namespace（如 pid、net）的隔离能力依赖于它提供的 UID 映射上下文。没有它，内核无法判断“这个新 PID 1 进程该以谁的身份运行”。
- 容器运行时（如 runc）内部一定按
CLONE_NEWUSER→CLONE_NEWPID→CLONE_NEWNET顺序调用clone() - 即使只想要网络隔离，也得带上
--user并做 UID 映射，否则非 root 用户无法安全启用--net - systemd-run 默认不启用 user namespace，所以
systemd-run --scope --property=Delegate=yes ……不能替代unshare
真实生产中绕不开的三个补丁点
纯 unshare 方案在生产环境几乎不可用，必须补足三处缺失能力：
- cgroup v2 接口绑定：用
mkdir /sys/fs/cgroup/myapp && echo $$ > /sys/fs/cgroup/myapp/cgroup.procs限制 CPU/memory，否则进程仍可抢占全部资源 - seccomp-bpf 过滤：默认允许全部系统调用，需用
scmp_bpf_compile()或crun run --seccomp ……屏蔽ptrace、mount、keyctl等高危调用 - capability drop：即使在 user namespace 中，进程默认仍有
CAP_SYS_ADMIN（若未显式丢弃），而该 cap 允许突破 mount/pid namespace 边界
最容易被忽略的是 capability 和 seccomp 的协同：只 drop capability 不过滤 syscalls，攻击者仍可通过 openat(AT_EMPTY_PATH) + ioctl(TIOCGDEV) 探测宿主设备；只上 seccomp 不 drop cap，则某些被允许的 syscall（如 clone(CLONE_NEWNS)）仍可新建嵌套 namespace。
