[lxc-users] apparmor profile for systemd containers (WAS: Fedora container thinks it is not running)

[Serge Hallyn]

Quoting Fajar A. Nugraha (list at fajar.net):
> On Thu, May 29, 2014 at 5:08 AM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:
> > would systemd be happy with it being mounted by lxc using an
> > lxc.mount.entry?  I think that would be preferable to relaxing the
> > apparmor policy.  i.e.
> >
> > lxc.mount.entry = /sys/fs/cgroup/systemd sys/fs/cgroup/systemd none
> > bind,create=dir,optional 0 0
> >
> >
> Wouldn't that be shadowed by the container mounting its own /sys?

If lxc mounts /sys then systemd will leave it be.

> Stephane also pointed out in my (closed) pull request that it would also
> allow the container to mess with the hosts's resource allocation.

Yes, that's why lxc.mount.auto = cgroup:mixed is better.  But the above
mount entry is no worse than letting the container do it through
apparmor.

> This works (at least, tested with console and ssh login), and should be
> secure-enough (bind-mount the container subdir, instead of the whole
> systemd cgroup), but complicated.
> 
> ### snippet of config
> lxc.hook.mount = "/var/lib/lxc/f20/bin/create_container_systemd_cgroup"
> lxc.hook.post-stop = "/var/lib/lxc/f20/bin/remove_container_systemd_cgroup"
> ###
> 
> ### cat create_container_systemd_cgroup
> #!/bin/bash
> mkdir -p /sys/fs/cgroup/systemd/lxc/$LXC_NAME
> mount -t sysfs sysfs $LXC_ROOTFS_MOUNT/sys
> mount -t tmpfs none $LXC_ROOTFS_MOUNT/sys/fs/cgroup
> mkdir $LXC_ROOTFS_MOUNT/sys/fs/cgroup/systemd
> mount --bind /sys/fs/cgroup/systemd/lxc/$LXC_NAME
> $LXC_ROOTFS_MOUNT/sys/fs/cgroup/systemd
> ###
> 
> ### cat remove_container_systemd_cgroup
> #!/bin/bash
> [ -n "$LXC_NAME" ] && find /sys/fs/cgroup/systemd/lxc/$LXC_NAME -type d |
> tac | xargs rmdir
> ###
> 
> Is there a way to simplify this somehow for it to be more suitable in the
> template?

I suppose we could add a new a lxc.mount.auto = cgroup:systemd option which
only mounts name=systemd, read-only except for the container's own cgroup
which is rw?  But when I say we I don't really mean we :)