Can't get writable cgroups (v1) inside container without --privileged

[KCSesh]

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

/kind feature

Description
Feature request based on this post:
#8441

For some reason cgroup v1 support was not added.

Wondering if there was a reason, and if we can remove that functionality?

I am trying to remove the --priveleged in a new use-case that I have which uses Podman In Podman, and would instead like to be specific about my capabilities used. It seems at runtime that I get an error that /sys/fs/cgroups is read-only at runtime, and the only way to make it rw is to use the --priveleged flag.

This was fixed for cgroupsv2, but I am unfortunately using cgroupsv1.

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

Output of podman version:

Version:      3.3.0-dev
API Version:  3.3.0-dev
Go Version:   go1.16
Git Commit:   dffbf16b24ba971a96db753100b7f43f5d6df3f8
Built:        Thu Jun 10 16:39:20 2021
OS/Arch:      linux/arm64

Output of podman info:

host:
  arch: arm64
  buildahVersion: 1.21.1
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  - debug
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/local/bin/conmon'
    path: /usr/local/bin/conmon
    version: 'conmon version 2.0.29-dev, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "18.04"
  eventLogger: file
  hostname: pan-appliance
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 4.9.140
  linkmode: dynamic
  memFree: 31615795200
  memTotal: 33424560128
  ociRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: true
    capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 16712269824
  swapTotal: 16712269824
  uptime: 22h 9m 45.72s (Approximately 0.92 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /data/podman/test/root
  graphStatus: {}
  imageStore:
    number: 0
  runRoot: /data/podman/test/run
  volumePath: /data/podman/test/root/volumes
version:
  APIVersion: 3.3.0-dev
  Built: 1623343160
  BuiltTime: Thu Jun 10 16:39:20 2021
  GitCommit: dffbf16b24ba971a96db753100b7f43f5d6df3f8
  GoVersion: go1.16
  OsArch: linux/arm64
  Version: 3.3.0-dev

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

Manual install

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

Yes @ troubleshooting.
No @ latest.

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

[giuseppe]

That is a conscious decision. cgroup delegation is not safe on cgroup v1 and it is enabled only on cgroup v2.

[KCSesh]

But if it works via privileged, shouldn't I have the ability to do it through: --security-opt accepting the same risk?

Essentially privileged is doing way more than I need, and I am looking to have an option available outside of privileged.

[giuseppe]

--privileged is about what you can do inside the container, it doesn't grant you access to the host (at least not directly).

If you need writeable cgroups, you can just bind mount them: -v /sys/fs/cgroup:/sys/fs/cgroup:rw