Linux 中的 init_user 命名空间是什么？

Question

在浏览Linux内核代码时，我在kernel/capability.c中发现了以下两个函数。

1)

bool has_capability(struct task_struct *t, int cap)

/*Does a task have a capability in init_user_ns.*/

2)

bool has_ns_capability(struct task_struct *t, struct user_namespace *ns, int cap)

/*Does a task have a capability in a specific user ns.*/

第一个函数中提到的init_user命名空间是什么？

据我所知，一个流程要么有能力（让我们暂时不用担心流程的不同能力集），要么没有，那么如何才能说一个流程有能力到命名空间？

如果您查看cap_get_target_pid() 的定义，在同一个文件中，它只讨论使用给定 pid 获取进程的功能，而无需担心用户命名空间。这对我来说看起来更自然。

Answer 1

Linux 功能是在 Linux 2.2 中引入的，而命名空间是在 Linux 3.8 中引入的。因此，我认为既然它们是独立开发的，它们就应该独立存在。我现在意识到，在阅读了这些文章（Link1 和 Link2）之后，情况并非如此。

当需要允许低权限进程创建用户命名空间时，这两种技术的融合发生了。在创建的用户命名空间内部，进程可以拥有所有的能力，但在外部应该是无能为力的。因此，如果一个进程 P1 试图向另一个进程 P2 发送 IPC，而 P1 有发送 IPC 的能力，内核不仅要检查该能力，而且必须检查 P1 是否具有与用户相关的所需能力进程 P2 的命名空间。两个进程的用户命名空间可以完全不相交，彼此之间没有 IPC 能力，因此不能允许这种操作。但是，必须允许进程 P1 向其自己的用户命名空间中的所有进程发送 IPC。

来自this维基百科的文章，

Permissions for namespace of the other kinds are checked in the user namespace, they got created in.

正如Gil Hamilton 所指出的，init_user 命名空间 (init_user_ns) 只是根命名空间，即在启动时创建的用户命名空间。

Here 是我关于该主题的完整文章。

Answer 2

命名空间是容器的关键，例如docker 等。它们提供容器之间的资源隔离。

这个想法是每个容器都有用于许多属性类型的单独命名空间，包括进程和线程 ID、用户和组 ID、TCP/UDP 端口、网络接口、挂载的文件系统等。

每个容器都能够像整个系统一样运行。命名空间防止一个命名空间中的进程能够访问另一个命名空间中的进程（除非已配置），或者它们的操作无意中渗入另一个命名空间。

init_user 命名空间是属于底层主机系统的“用户命名空间”（也称为“根”命名空间）。由于命名空间是分层的，如果一个进程在 init_user 命名空间中，它的能力在根命名空间和所有其他命名空间中都有效（因为它们都是根命名空间的后代）。