Chapter 2: Process Management and Scheduling
Global identifiers allow the kernel to selectively grant or deny certain privileges. While the root user
with UID 0 is essentially allowed to do anything, higher user IDs are more confined. A user with PIDn
may, for instance, not kill processes that belong to userm=n. However, this does not prevent users from
seeingeach other: Userncan see that another usermis also active on the machine. This is no problem: As
long as users can only fiddle with their own processes, there is no reason why they should not be allowed
to observe that other users have processes as well.
There are cases, though, where this can be undesired. Consider that a web provider wants to give full
access to Linux machines to customers, including root access. Traditionally, this would require setting
up one machine per customer, which is a costly business. Using virtualized environments as provided
by KVM or VMWare is one way to solve the problem, but does not distribute resources very well: One
separate kernel is required for each customer on the machine, and also one complete installation of the
surrounding userland.
A different solution that is less demanding on resources is provided by namespaces. Instead of using
virtualized systems such that one physical machine can run multiple kernels — which may well be from
different operating systems — in parallel, a single kernel operates on a physical machine, and all previ-
ously global resources are abstracted innamespaces. This allows for putting a group of processes into a
container, and one container is separated from other containers. The separation can be such that members
of one container have no connection whatsoever with other containers. Is is, however, also possible to
loosen the separation of containers by allowing themto share certain aspects of their life. For instance,
containers could be set up to use their own set of PIDs, but still share portions of filesystems with each
other.
Namespaces essentially create differentviewsof the system. Every formerly global resource must be
wrapped up in a container data structure, and only tuples of the resource and the containing namespace
are globally unique. While the resource alone is enough inside a given container, it does not provide a
unique identity outside the container. An overview of the situation is given in Figure 2-3.
Consider a case in which three different namespaces are present on the system. Namespaces can be
hierarchically related, and I consider this case here. One namespace is the parent namespace, which has
spawned two child namespaces. Assume that the containers are used in a hosting setup where each
container must look like a single Linux machine. Each of them therefore has its owninittask with PID
0, and the PIDs of other tasks are assigned in increasing order. Both child namespaces have an init task
with PID 0, and two processes with PIDs 2 and 3, respectively. Since PIDs with identical values appear
multiple times on the system, the numbers are not globally unique.
While none of the child containers has any notion about other containers in the system, the parent is
well informed about the children, and consequently sees all processes they execute. They are mapped
to the PID range 4 to 9 in the parent process. Although there are 9 processes on the system, 15 PIDs are
required to represent them because one process can be associated with more than one PID. The ‘‘right’’
one depends on the context in which the process is observed.
Namespaces can also be non-hierarchical if they wrap simpler quantities, for instance, like the UTS
namespace discussed below. In this case, there is no connection between parent and child namespaces.
Notice that support for namespaces in a simple form has been available in Linux for quite a long time
in the form of thechrootsystem call. This method allows for restricting processes to a certain part of
