1

在浏览 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 获取进程的功能,而不用担心用户命名空间。这对我来说看起来更自然。

4

2 回答 2

3

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

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

这篇维基百科文章中,

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

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

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

于 2016-09-22T15:27:02.963 回答
0

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

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

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

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

于 2016-09-21T21:52:44.753 回答