I’ve been experimentint with LXC as of late, and I’ve found that systemd-run (suggested by the docs) is not always needed for unprivileged containers.
Particularly, it’s not needed locally on Arch Linux.
On an Ubuntu server (w/o systemd-run) I get:
lxc-start c 20221030114914.612 WARN apparmor -
lsm/apparmor.c:lsm_apparmor_ops_init:1275 - Per-container AppArmor
profiles are disabled because the mac_admin capability is missing
lxc-start c 20221030114914.626 WARN start - start.c:lxc_spawn:1835
- Operation not permitted - Failed to allocate new network namespace
id
And in the container’s console:
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[^[[0;1;31m!!!!!!^[[0m] Failed to mount API filesystems.
Exiting PID 1...
I asked around on the systemd-devel mailing list, and from the replies it looks like Delegate=yes is not about permissions, but is a way to tell the host’s systemd to not touch a cgroup subtree. Yet from the output it looks like it’s about permissions. I understand that systemd-run creates a transient user scope with Delegate=yes, but why is it not always needed?
On a related note, I tried to run it locally under a different user (useradd + su), and it failed, be it w/ or w/o systemd-run. systemd-run itself doesn’t work:
Failed to connect to bus: No medium found
And I wonder if there’s an easy way to make it (LXC) work under a different user.
Detailed logs can be found here.