在浏览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获取进程的功能，而不必担心用户命名空间。这看起来更自然。
答案 0 :(得分：0)
命名空间是容器的关键，例如docker等。它们在容器之间提供资源隔离。
这个想法是每个容器都有许多属性类型的名称空间，包括进程和线程ID，用户和组ID，TCP / UDP端口，网络接口，挂载的文件系统等。
每个容器的行为都像整个系统一样。名称空间阻止一个名称空间中的进程能够访问另一个名称空间中的进程（除了已配置），或者它们的操作无意中流入另一个名称空间。
init_user命名空间是＆＃34;用户命名空间＆＃34;属于底层主机系统（又名＆＃34; root＆＃34;命名空间）。由于名称空间是分层的，如果进程位于init_user名称空间中，则其功能在根名称空间和所有其他名称空间中都有效（因为它们都是根名称空间的后代）。
答案 1 :(得分：0)
Linux 2.2中引入了Linux功能，而Linux 3.8中引入了名称空间。因此，我认为，因为它们是独立发展的，所以它们应该独立存在。正如我现在所知，在阅读这些文章（Link1和Link2）后，情况并非如此。
当需要允许弱势进程创建用户名称空间时，就会出现这两种技术的融合。在创建的用户命名空间内，该进程可以具有所有功能，但外部应该无能为力。因此，如果进程P1试图将IPC发送到另一个进程P2，并且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是我对该主题的完整描述。