[pkg-lxc-devel] Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)

[Matthijs Kooijman]

Hey folks,

I've upgraded this system to buster and it seems that either the new
kernel (4.19.0-8-amd64) or new lxc version (1:3.1.0+really3.0.3-8) has
fixed this problem: I can now again re-exec systemd in containers even
with lxc.cap.drop = sys_admin enabled.

I guess this issue could be closed? Feel free to do so if you think it
is appropriate.


Anyway, below is some more info I collected a long time ago but never
gotten around to cleaning up and sending. I'm including it here, in case
it is useful for anyone else running into the same.

Gr.

Matthijs

== Old debugging info below ==

When running systemd with debug loglevel (in /etc/systemd/system.conf),
I see the following on boot (from the console logfile, since journald
isn't running at that point yet):

	Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd.
	Release agent already installed.

When reexecuting systemd, I get the following (from journalctl):

	Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd/../...
	Release agent already installed.
	Failed to create /../../init.scope control group: Operation not permitted
	Failed to allocate manager object: Operation not permitted


The ../../init.scope is, I think, based on this file:

	$ cat /proc/1/cgroup
	10:freezer:/
	9:pids:/../../init.scope
	8:net_cls,net_prio:/
	7:devices:/../../init.scope
	6:blkio:/../../init.scope
	5:memory:/../../init.scope
	4:perf_event:/
	3:cpu,cpuacct:/../../init.scope
	2:cpuset:/
	1:name=systemd:/../../init.scope

This is how it looks before and after the re-exec.

I'm not sure what this file looks like when systemd first starts in the
container, but I suspect the ../../ is not there yet, given the "File
system hierarchy is at /sys/fs/cgroup/systemd" log message, or maybe
systemd does not read it on initial startup?

On the host, the file looks like this:

	$ cat /proc/1/cgroup
	10:freezer:/
	9:pids:/init.scope
	8:net_cls,net_prio:/
	7:devices:/init.scope
	6:blkio:/init.scope
	5:memory:/init.scope
	4:perf_event:/
	3:cpu,cpuacct:/init.scope
	2:cpuset:/
	1:name=systemd:/init.scope

When I look up the container's pid 1 on the host, it looks like this:

matthijs at tika:/etc/lxc$ cat   /proc/1755/cgroup
10:freezer:/lxc/template
9:pids:/init.scope
8:net_cls,net_prio:/lxc/template
7:devices:/init.scope
6:blkio:/init.scope
5:memory:/init.scope
4:perf_event:/lxc/template
3:cpu,cpuacct:/init.scope
2:cpuset:/lxc/template
1:name=systemd:/init.scope


When I start the container *with* CAP_SYS_ADMIN, the file inside the
container looks different:

matthijs at template:~$ cat /proc/1/cgroup | grep systemd
1:name=systemd:/init.scope

When I look up the container's pid 1 on the host, it looks like this:

matthijs at tika:/etc/lxc$ sudo cat /proc/507/cgroup | grep systemd
1:name=systemd:/lxc/template/init.scope

== New debug info ==

After the upgrade to buster, it seems that the scopes are now correct.
Inside the container *without* CAP_SYS_ADMIN, I now get:

$ cat /proc/1/cgroup |grep systemd
1:name=systemd:/init.scope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20200411/e5b861ee/attachment.sig>