Can't get writable cgroups inside container without --priveleged

[mejedi]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Containerised app uses cgroups v2 for sandboxing internally (runs untrusted code). Podman run exposes cgroups but they are RO, unless I pass --priveleged. The latter seems excessive though. Would be nice if it was possible to request writable cgroups via e.g. --security-opt.

Steps to reproduce the issue:

1. podman run alpine mkdir /sys/fs/cgroup/eee

Describe the results you received:

$ podman run  alpine mkdir /sys/fs/cgroup/eee
mkdir: can't create directory '/sys/fs/cgroup/eee': Read-only file system

Describe the results you expected:

$ podman run --privileged alpine mkdir /sys/fs/cgroup/eee

(succeeds)

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.20, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "19.10"
  eventLogger: journald
  hostname: u1.local
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.3.0-64-generic
  linkmode: dynamic
  memFree: 212668416
  memTotal: 4113747968
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version UNKNOWN
      commit: 3e46dd849fdf6bfa68127786e073318184641f05
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 0.4.1
      commit: 4d38845e2e311b684fc8d1c775c725bfcd5ddc27
  swapFree: 4124045312
  swapTotal: 4126142464
  uptime: 36m 54.72s
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/nickz/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/nickz/.local/share/containers/storage
  graphStatus: {}
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  volumePath: /home/nickz/.local/share/containers/storage/volumes
version:
  APIVersion: 2.0.0
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 2.1.1

Package info (e.g. output of rpm -q podman or apt list podman):

podman/unknown,now 2.1.1~2 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

VirtualBox

[rhatdan]

@umohnani8 PTAL
@giuseppe WDYT? Is this something that should be read/writable by default in a container with cgroups V2? Since we have delegation, isn't it safe to allow the container to subdevice its cgroups?

[giuseppe]

I think adding an option to --security-opt for enabling writeable cgroups is a good idea.

I think we should not do it by default. Creating cgroups can be expensive, we have the same issue with systemd not delegating the cpu controller to rootless users, and a malicious container could take advantage of it.

[rhatdan]

@umohnani8 Since you are already in the --security-opt code, could you look into adding this feature.

How about
--security-opt cgroups=rw

Should this only be available to cgroups V2? (That is where I am leaning).

[giuseppe]

yes, probably it is a good idea to allow it only for cgroups v2. If there is any need for cgroup v1 we can always add it later

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@umohnani8 Do you have a chance to look at this? @giuseppe would you like to work on it?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@umohnani8 @giuseppe Might have got lost during Holiday Break.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

I just ran these commands as rootless and it seems to work for me.

 podman run -ti --privileged alpine sh
/ # mkdir /sys/fs/cgroup/eee
/ # ls -l /sys/fs/cgroup/eee/
total 0
-r--r--r--    1 root     root             0 Feb 26 09:47 cgroup.controllers
-r--r--r--    1 root     root             0 Feb 26 09:47 cgroup.events
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.freeze
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.max.depth
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.max.descendants
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.procs
-r--r--r--    1 root     root             0 Feb 26 09:47 cgroup.stat
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.subtree_control
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.threads
-rw-r--r--    1 root     root             0 Feb 26 09:47 cgroup.type
-rw-r--r--    1 root     root             0 Feb 26 09:47 cpu.pressure
-r--r--r--    1 root     root             0 Feb 26 09:47 cpu.stat
-rw-r--r--    1 root     root             0 Feb 26 09:47 io.pressure
-rw-r--r--    1 root     root             0 Feb 26 09:47 memory.pressure
/ # 

[rhatdan]

$ podman -v
podman version 3.0.1

[mejedi]

@rhatdan
What does --priveleged option do in rootless mode? The issue was about getting cgroups w/o going priveleged.

[rhatdan]

oops.

 ./bin/podman run --security-opt unmask=/sys/fs/cgroup alpine mkdir /sys/fs/cgroup/eee
mkdir: can't create directory '/sys/fs/cgroup/eee': Read-only file system

This should work.

[jmguzik]

@rhatdan From the description, it looks like it won't be overcomplicated.
I could try to look at this one in the coming days.
Unfortunately, I can't commit to huge tasks due to lack of time, so if my understanding is bad, please tell me right away.

[jmguzik]

Proposed solution presented in PR