1

While browsing Linux kernel code, I found the following two functions in 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.*/

What is the init_user namespace mentioned in the first function?

From what I know, a process either has a capability (let us not worry about the different capability sets of a process for now), or it doesn't, so how can a process be said to have a capability with respect to a namespace?

If you look at the definition of cap_get_target_pid(), in the same file, it just talks about getting capabilities of a process with the given pid, without worrying about the user namespace. This looks more natural to me.

tomix86
  • 1,336
  • 2
  • 18
  • 29
Sahil Singh
  • 3,352
  • 39
  • 62

2 Answers2

3

Linux capabilities were introduced in Linux 2.2, while namespaces were introduced in Linux 3.8. I therefore though that since they were developed independently, they should have independent existence. As I now realise, after reading these articles (Link1 and Link2) the situation is not quite so.

The confluence of the two technologies occurred when there was a need of allowing underprivileged processes to create user namespaces. Inside the created user namespace, the process could have all the capabilities but it should be powerless outside. Thus, if a process P1 is trying to send IPC to another process P2, and P1 has the capability to send IPC, the kernel must not just check for the capability, but it must check whether P1 has the required capability with respect to the user namespace of the process P2. The user namespaces of the two processes can be completely disjoint, with no IPC capabilities over one another, hence this operation must not be allowed. However, process P1 must be allowed to send IPC to all processes in its own user namespace.

From this wikipedia article,

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

As pointed out by Gil Hamilton, the init_user namespace (init_user_ns) is just the root namespace, i.e. the user namespace that is created at boot time.

Here is my complete writeup on the topic.

Community
  • 1
  • 1
Sahil Singh
  • 3,352
  • 39
  • 62
0

Namespaces are the key to containers, such as docker and the like. They provide resource isolation between the containers.

The idea is that each container has separate namespaces for a number of attribute types, including process and thread IDs, user and group IDs, TCP/UDP ports, network interfaces, mounted filesystems, etc.

Each container is able to behave as if it were the entire system. The namespaces prevent processes in one namespace from being able to access those in another (except as configured), or their actions inadvertently bleeding over into another.

The init_user namespace is the "user namespace" belonging to the underlying host system (aka the "root" namespace). Since namespaces are hierarchical, if a process is in the init_user namespace, its capabilities are effective in the root namespace and all others (since they are all descendants of the root namespace).

Gil Hamilton
  • 11,973
  • 28
  • 51