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 (
su), and it failed, be it w/ or w/o
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.