1CGROUP_NAMESPACES(7)       Linux Programmer's Manual      CGROUP_NAMESPACES(7)
2
3
4

NAME

6       cgroup_namespaces - overview of Linux cgroup namespaces
7

DESCRIPTION

9       For an overview of namespaces, see namespaces(7).
10
11       Cgroup  namespaces  virtualize  the  view  of  a process's cgroups (see
12       cgroups(7)) as seen via /proc/[pid]/cgroup and /proc/[pid]/mountinfo.
13
14       Each cgroup namespace has its  own  set  of  cgroup  root  directories.
15       These  root  directories are the base points for the relative locations
16       displayed in the corresponding records in the /proc/[pid]/cgroup  file.
17       When  a  process  creates  a new cgroup namespace using clone(2) or un‐
18       share(2) with the CLONE_NEWCGROUP flag, its current cgroups directories
19       become the cgroup root directories of the new namespace.  (This applies
20       both for the cgroups version 1 hierarchies and the  cgroups  version  2
21       unified hierarchy.)
22
23       When  reading  the  cgroup  memberships  of  a  "target"  process  from
24       /proc/[pid]/cgroup, the pathname shown  in  the  third  field  of  each
25       record will be relative to the reading process's root directory for the
26       corresponding cgroup hierarchy.  If the cgroup directory of the  target
27       process lies outside the root directory of the reading process's cgroup
28       namespace, then the pathname will show ../ entries  for  each  ancestor
29       level in the cgroup hierarchy.
30
31       The  following  shell session demonstrates the effect of creating a new
32       cgroup namespace.
33
34       First, (as superuser) in a shell in the initial  cgroup  namespace,  we
35       create  a child cgroup in the freezer hierarchy, and place a process in
36       that cgroup that we will use as part of the demonstration below:
37
38           # mkdir -p /sys/fs/cgroup/freezer/sub2
39           # sleep 10000 &     # Create a process that lives for a while
40           [1] 20124
41           # echo 20124 > /sys/fs/cgroup/freezer/sub2/cgroup.procs
42
43       We then create another child cgroup in the freezer  hierarchy  and  put
44       the shell into that cgroup:
45
46           # mkdir -p /sys/fs/cgroup/freezer/sub
47           # echo $$                      # Show PID of this shell
48           30655
49           # echo 30655 > /sys/fs/cgroup/freezer/sub/cgroup.procs
50           # cat /proc/self/cgroup | grep freezer
51           7:freezer:/sub
52
53       Next,  we use unshare(1) to create a process running a new shell in new
54       cgroup and mount namespaces:
55
56           # PS1="sh2# " unshare -Cm bash
57
58       From  the  new  shell  started  by  unshare(1),  we  then  inspect  the
59       /proc/[pid]/cgroup  files  of,  respectively,  the new shell, a process
60       that is in the initial cgroup namespace (init, with  PID  1),  and  the
61       process in the sibling cgroup (sub2):
62
63           sh2# cat /proc/self/cgroup | grep freezer
64           7:freezer:/
65           sh2# cat /proc/1/cgroup | grep freezer
66           7:freezer:/..
67           sh2# cat /proc/20124/cgroup | grep freezer
68           7:freezer:/../sub2
69
70       From  the  output  of the first command, we see that the freezer cgroup
71       membership of the new shell (which is in the same cgroup as the initial
72       shell)  is  shown defined relative to the freezer cgroup root directory
73       that was established when the new cgroup namespace  was  created.   (In
74       absolute  terms,  the  new shell is in the /sub freezer cgroup, and the
75       root directory of the freezer cgroup hierarchy in the new cgroup  name‐
76       space  is  also  /sub.  Thus, the new shell's cgroup membership is dis‐
77       played as '/'.)
78
79       However, when we look in  /proc/self/mountinfo  we  see  the  following
80       anomaly:
81
82           sh2# cat /proc/self/mountinfo | grep freezer
83           155 145 0:32 /.. /sys/fs/cgroup/freezer ...
84
85       The  fourth  field of this line (/..)  should show the directory in the
86       cgroup filesystem which forms the root of this  mount.   Since  by  the
87       definition  of  cgroup namespaces, the process's current freezer cgroup
88       directory became its root freezer cgroup directory, we should  see  '/'
89       in  this  field.   The problem here is that we are seeing a mount entry
90       for the cgroup filesystem corresponding to the initial cgroup namespace
91       (whose  cgroup  filesystem  is indeed rooted at the parent directory of
92       sub).  To fix this problem, we must remount the freezer cgroup filesys‐
93       tem  from the new shell (i.e., perform the mount from a process that is
94       in the new cgroup namespace), after which we see the expected results:
95
96           sh2# mount --make-rslave /     # Don't propagate mount events
97                                          # to other namespaces
98           sh2# umount /sys/fs/cgroup/freezer
99           sh2# mount -t cgroup -o freezer freezer /sys/fs/cgroup/freezer
100           sh2# cat /proc/self/mountinfo | grep freezer
101           155 145 0:32 / /sys/fs/cgroup/freezer rw,relatime ...
102

CONFORMING TO

104       Namespaces are a Linux-specific feature.
105

NOTES

107       Use of cgroup namespaces requires a kernel that is configured with  the
108       CONFIG_CGROUPS option.
109
110       The  virtualization  provided  by  cgroup namespaces serves a number of
111       purposes:
112
113       * It prevents information leaks whereby cgroup directory paths  outside
114         of  a  container  would otherwise be visible to processes in the con‐
115         tainer.  Such leakages could, for example, reveal  information  about
116         the container framework to containerized applications.
117
118       * It  eases tasks such as container migration.  The virtualization pro‐
119         vided by cgroup namespaces allows  containers  to  be  isolated  from
120         knowledge  of the pathnames of ancestor cgroups.  Without such isola‐
121         tion, the full cgroup  pathnames  (displayed  in  /proc/self/cgroups)
122         would  need  to  be  replicated on the target system when migrating a
123         container; those pathnames would also need to be unique, so that they
124         don't conflict with other pathnames on the target system.
125
126       * It  allows  better confinement of containerized processes, because it
127         is possible to mount the container's cgroup filesystems such that the
128         container processes can't gain access to ancestor cgroup directories.
129         Consider, for example, the following scenario:
130
131           • We have a cgroup directory, /cg/1, that is owned by user ID 9000.
132
133           • We have a process, X, also owned by user ID 9000, that is  names‐
134             paced  under  the  cgroup  /cg/1/2  (i.e.,  X was placed in a new
135             cgroup namespace via clone(2) or unshare(2) with the  CLONE_NEWC‐
136             GROUP flag).
137
138         In  the  absence  of cgroup namespacing, because the cgroup directory
139         /cg/1 is owned (and writable) by UID 9000 and process X is also owned
140         by  user  ID  9000, process X would be able to modify the contents of
141         cgroups files (i.e., change cgroup settings) not only in /cg/1/2  but
142         also  in  the ancestor cgroup directory /cg/1.  Namespacing process X
143         under the cgroup directory  /cg/1/2,  in  combination  with  suitable
144         mount operations for the cgroup filesystem (as shown above), prevents
145         it modifying files in /cg/1, since it cannot even see the contents of
146         that  directory  (or of further removed cgroup ancestor directories).
147         Combined with correct enforcement of hierarchical limits,  this  pre‐
148         vents process X from escaping the limits imposed by ancestor cgroups.
149

SEE ALSO

151       unshare(1),  clone(2),  setns(2), unshare(2), proc(5), cgroups(7), cre‐
152       dentials(7), namespaces(7), user_namespaces(7)
153

COLOPHON

155       This page is part of release 5.10 of the Linux  man-pages  project.   A
156       description  of  the project, information about reporting bugs, and the
157       latest    version    of    this    page,    can     be     found     at
158       https://www.kernel.org/doc/man-pages/.
159
160
161
162Linux                             2020-11-01              CGROUP_NAMESPACES(7)
Impressum