Skip to content

Commit 42c0604

Browse files
specify cgroup ownership semantics
cgroups v2 supports secure delegation of cgroups. Accordingly, control over a cgroup (that is, creation of new child cgroups and movement of processes and threads among the cgroup subtree exposed to a container) can be safely delegated to a container. Adjusting the ownership enables real-world use cases like systemd-based containers fully isolated in user namespaces. To encourage adoption of this feature, and secure implementation, define the semantics of cgroup ownership. Changing/setting the cgroup ownership should only be performed when: - using cgroups v2, and - container will have a new cgroup namespace, and - cgroupfs will be mounted read/write. The specific files whose ownership should be changed are listed. In terms of current practice, this is already the behaviour of crun (which also chown's the memory.oom.group file), and there is a pull request for runc: opencontainers/runc#3057. Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>
1 parent ab23082 commit 42c0604

1 file changed

Lines changed: 38 additions & 0 deletions

File tree

config-linux.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -196,6 +196,44 @@ For example, to run a new process in an existing container without updating limi
196196

197197
Runtimes MAY attach the container process to additional cgroup controllers beyond those necessary to fulfill the `resources` settings.
198198

199+
### Cgroup ownership
200+
201+
Runtimes MAY change (or cause to be changed) the owner of the
202+
container's cgroup to the host uid that maps to uid 0 in the
203+
container's user namespace, according to the following rules.
204+
205+
Runtimes SHOULD NOT change the ownership of container cgroups when
206+
cgroups v1 is in use. Cgroup delegation is not secure in cgroups
207+
v1.
208+
209+
A runtime SHOULD NOT change the ownership of a container cgroup
210+
unless it will also create a new cgroup namespace for the container.
211+
Typically this occurs when the `linux.namespaces` array contains an
212+
object with `type` equal to `"cgroup"` and `path` unset.
213+
214+
Runtimes SHOULD change the cgroup ownership if and only if the
215+
cgroup filesystem is to be mounted read/write; that is, when the
216+
configuration's `mounts` array contains an object where:
217+
218+
- The `source` field is equal to `"cgroup"`
219+
- The `destination` field is equal to `"/sys/fs/cgroup"`
220+
- The `options` field does not contain the value `"ro"`
221+
222+
If the configuration does not specify such a mount, the runtime
223+
SHOULD NOT change the cgroup ownership.
224+
225+
A runtime that changes the cgroup ownership SHOULD only change the
226+
ownership of the container's cgroup directory and the following
227+
files within that directory:
228+
229+
- `cgroup.procs`
230+
- `cgroup.subtree_control`
231+
- `cgroup.threads`
232+
233+
The runtime SHOULD NOT change the ownership of any other files.
234+
Changing other files may allow the container to elevate its own
235+
resource limits or perform other unwanted behaviour.
236+
199237
### Example
200238

201239
```json

0 commit comments

Comments
 (0)