问题
我想启动一个 Docker 容器，它运行一个可能会也可能不会克隆自身的进程。
是否可以设置一个具有正常 + clone_newuts 权限的用户，这样我的容器就没有超级用户的登录用户？
最初这个问题被标记为：CLONE_NEWUTS permission only，这是不正确的。 @sourcejedi 在下面真诚地回答并大大提高了我的理解。
编辑-1
我找到了 su 标志的保存位置：/usr/include/linux/sched.h，我希望答案是类似于猴子修补容器创建上的特定用户权限。我现在要沿着那条路走，看看它会把我带到哪里。
编辑2
我找到了可以设置用户/文件功能的位置。我发现我有很多阅读要做，但我认为可以向文件授予特定权限（功能）（在本例中该文件是可执行的）。从功能手册页来看：
Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.
因此，应该可以将特定功能（其标志在上面的标头中找到）应用于文件或用户。我还不确定是哪一个，但找出这一点会变得非常有趣和深入。
编辑-3
正如@sourcejedi 指出的那样，我误解了我的需求。必要的信息位于 中man limits.conf，其中可以在指定的用户级别运行进程，在本例中为root。
编辑4
不幸的是，我从 EDIT-3 采取的路线也是不正确的。这允许指定用户运行全部指定 uesr 级别的进程。 @sourcejedi 仍然是正确的，但是我将提出一个新问题，询问我真正需要什么。关联：运行可以以非 root 用户身份分叉和克隆的单个进程
答案1
没有能力专门允许使用该CLONE_NEWUTS标志调用clone()。
CLONE_NEWUTS用于创建并输入新的“UTS命名空间”。所有命名空间类型都需要CAP_SYS_ADMIN创建，但有一个例外：上游 Linux 内核允许非特权用户创建并输入新的用户命名空间。
当您创建用户命名空间时，您可以允许自己拥有root/完整权限里面该命名空间，包括CAP_SYS_ADMIN.如果您的系统支持此功能，您可以使用 来查看它unshare -r。它在新的用户命名空间中打开一个 root shell。
非特权用户使用命名空间的预期方法是在新的用户命名空间内。然而，一些 Linux 发行版将内核配置为不允许此功能。
CAP_SYS_ADMIN用作任何没有更具体功能的事物的总称。它太强大了。您应该假设它可以用于接管其他程序，从而获得任何其他功能。[1]
Docker守护进程的默认配置不将任何容器放置在新的用户命名空间中。因此，您应该假设显式授予CAP_SYS_ADMINdocker 容器允许它以完全权限转义容器。[1]
如果非特权用户可以直接创建所有类型的命名空间，则会引发问题，命名空间可能会被用来迷惑 setuid 程序，执行不应该执行的特权操作。交叉引用：“为什么取消共享挂载命名空间需要 CAP_SYS_ADMIN？”
另一种选择是使用具有 setuid/capability 的帮助程序可执行文件，该可执行文件仅允许执行特定任务。就像如何sudo配置为仅允许运行特定的特权命令。这是采取的方法泡沫包装，由 FlatPak 使用。
bubblewrap 自述文件还提供了一些有关导致 Linux 发行版限制用户命名空间的安全问题的参考资料。
我认为这个故事与“Docker in Docker”没有得到真正支持/如果不禁用主 Docker 守护进程中的重要安全功能就不可能实现的原因重叠。虽然不完全一样。
[1] 例如，CAP_SYS_ADMIN用于挂载块文件系统的功能，内核开发人员认为无法可靠地防范恶意 FS 映像。
在新的用户命名空间内，CAP_SYS_ADMIN不允许您挂载块文件系统。但是，如果您还创建了一个新的挂载命名空间 - 例如unshare -rm- CAP_SYS_ADMIN 将允许您创建绑定挂载、挂载proc文件系统，并且在内核 4.18 或更高版本中您可以挂载 FUSE 文件系统。
Docker 还在可用的系统上使用基于 LSM 的安全性 - SELinux 或 AppArmor。这些层可能会CAP_SYS_ADMIN在某些方面受到限制。这比 Docker 的其他安全层更加晦涩难懂。如果您依赖于特定 LSM 的详细工作原理，那么这似乎就违背了构建方便的便携式 Docker 容器的要点之一。