man 2 unshare告诉我们
使用 CLONE_NEWPID 需要 CAP_SYS_ADMIN 功能
并且建议阅读更多信息man 7 pid_namespaces并没有真正讨论可能的风险，该风险使得有必要将 pid_namespaces 限制为仅 root/CAP_SYS_ADMIN。
CLONE_NEWPID如果由非 root 用户运行会有什么风险？
在克隆中没有 CLONE_NEWPIDpid_namespace 将保持不变，因此比创建新的空 pid_namespace 的情况更广泛且可能更危险。
可悲的是，没有一些概念用户 PID 命名空间对于非 root 用户来说，在 Linux 中可靠地跟踪后代进程变得很困难。 pid_namespaces 将是非常方便的功能，因此我无法理解为什么只CAP_SYS_ADMIN认为适合运行CLONE_NEWPID。我是否错过了导致如此危险的忙碌的一个要点CLONE_NEWPID？
答案1
我认为这是一种预防措施。不允许非特权用户对诸如sudoset-user-id（或设置文件功能）之类的程序应用限制，以免使他们混淆执行他们不打算允许的操作。
在某些情况下，这是通过防止 set-uid 等提升来强制执行的。这是使用 seccomp 过滤系统调用时所采用的方法。
然而对于命名空间来说，其目的是允许命名空间用户 ID。命名空间以渐进的方式合并到主线 Linux 中，从最简单的开始，最终形成用户命名空间。我怀疑当您还没有完全权限时，没有人有兴趣添加特殊情况，以在进入 PID 命名空间时强制执行 no-new-privs。
这些命名空间的交互变得非常复杂，因此最好不要增加太多不同的情况，如果这些情况的需求不是很高的话。