This is a new approach to #1302 with a container-side
configuration instead of a global boolean flag.
Contrary to the previous PR using an optional additional
parameter for the get-cgroup command, this introduces two
new additional commands to get the limiting cgroup path and
cgroup2 file descriptor. If the limiting option is not in
use, these behave identical to their full-path counterparts.
If these variables are used the payload will end up in the
concatenation of lxc.cgroup.dir.container and
lxc.cgroup.dir.container.inner (which may be empty), and the
monitor will end up in lxc.cgruop.dir.monitor. The
directories are fixed, no retry count logic is applied,
failing to create these directories will simply be a hard
error.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
GCC 7 appears to be clever enough to detect that transient_len is
uninitialised but not that it won't be used despite [1]. Just initialise
it to zero to stop the complaining, and allow LXC to build on openSUSE
Leap.
[1]: 346830421a ("cgroups: fix "uninitialized transient_len" warning")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Without this change, a build error is triggered if you compile with
-Werror=maybe-uninitialized.
cgroups/cgfsng.c: In function 'cgfsng_monitor_enter':
groups/cgfsng.c:1387:9: error: 'transient_len' may be used uninitialized in this function
ret = lxc_writeat(h->cgfd_mon, "cgroup.procs", transient, transient_len);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The issue is that if handler->transient_pid is 0, then transient_len is
uninitialised but lxc_writeat(..., transient_len) still gets called.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
lxc-monitord instances are spawned on demand and, if this
happens from a service, the daemon is considered part of
it by systemd, as it is running in the same cgroups. This
can be avoided by leaving it running permanently.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
On olders kernels the restrictions to move processes between cgroups are
different than they are on newer kernels. Specifically, we're running into the
following check:
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
!uid_eq(cred->euid, tcred->suid))
ret = -EACCES;
which dictates that in order to move a process into a cgroup one either needs
to be global root (no restrictions apply) or the effective uid of the process
trying to move the process and the {saved}uid of the process that is supposed
to be moved need to be identical. The new attaching logic we did didn't
fulfill this criterion for because it's not present on new kernels.
Closes https://github.com/lxc/lxd/issues/7104.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
validate that a cgroup controller name is a valid
zero-terminated string before passing it to
`cgroup_ops->get_cgroup()`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Writing the value 0 to a cgroup.procs file causes the
writing process to be moved to the corresponding cgroup
Signed-off-by: cenxianlong <cenxianlong@huawei.com>
