cgroup_namespaces(7)

1cgroup_namespaces(7)   Miscellaneous Information 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  record
25       will be relative to the reading process's root directory for the corre‐
26       sponding 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 that
60       is in the initial cgroup namespace (init, with PID 1), and the  process
61       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

STANDARDS

104       Linux.
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
124          they 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
128          the  container processes can't gain access to ancestor cgroup direc‐
129          tories.  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
140          owned  by  user  ID 9000, process X would be able to modify the con‐
141          tents of cgroups files (i.e., change cgroup settings)  not  only  in
142          /cg/1/2  but also in the ancestor cgroup directory /cg/1.  Namespac‐
143          ing process X under the cgroup  directory  /cg/1/2,  in  combination
144          with  suitable  mount operations for the cgroup filesystem (as shown
145          above), prevents it modifying files in /cg/1, since it  cannot  even
146          see the contents of that directory (or of further removed cgroup an‐
147          cestor directories).  Combined with correct enforcement  of  hierar‐
148          chical  limits, this prevents process X from escaping the limits im‐
149          posed by ancestor cgroups.
150

NAME

DESCRIPTION

STANDARDS

NOTES

SEE ALSO