According to a Bug report on ArchLinux (Bug 70329), pam_cgfs does not really support cgroup v2.
Workarounds include:
use cgroup v1
use systemd delegate
Is that correct?
Is the use of systemd delegate intended?
In case pam_cgfs does not support cgroup v2, how to use it then?
According to LXC 4.0 LTS has been released cgroup v2 should be suppported already.
For reference:
the Arch Wiki lists the following instructions for unpriviledged container support:
Enable the [control groups](https://wiki.archlinux.org/index.php/Control_groups) [PAM](https://wiki.archlinux.org/index.php/PAM) module by modifying `/etc/pam.d/system-login` to additionally contain the following line:
session optional pam_cgfs.so -c freezer,memory,name=systemd,unified
Systemd usually creates per-user/per-session cgroups, in a v2 hierarchy, it should be able to at least create things properly, though possibly not with the right permissions.
pam_cgfs can’t work with the pure unified layouts. I’m repeating mostly
verbatim from an old issue in 2019 I commented on:
The cgroup2 hierarchy has an internal process constraint. In short,
there can only be processes in a cgroup with controllers enabled if it’s
a leaf node. When you log into your system systemd on cgroup2-only
hosts will place you in a session.scope for your user, i.e. you are now
on a leaf node and can’t have subcgroup with controllers enabled and
live processes in it. The kernel will prevent that. All your processes
including privileged processes your session needs will live in this
sesscion scope. This means before you could start any container with
actual controllers enabled you would need to move your whole session,
i.e. all the processes assigned to it into a separate cgroup in your
session scope and then create the cgroups for the container in the now
empty session scope. That’s not just out of scope for LXC itself we
also can’t just move your user or your session around the hierarchy.
That’s a no-go security wise and also way to heavy handed.
