[lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail

[Christian Brauner]

> Quoting Christian Brauner (christianvanbrauner at gmail.com):
> > > On Sun, Feb 15, 2015 at 05:21:19PM +0100, Christian Brauner wrote:
> > > > Hello,
> > > > 
> > > > I test the newest systemd from git on a regular basis by compiling it
> > > > and installing it into a container and booting it. I did that with the
> > > > several current systemd versions from git for the last couple of
> > > > weeks.
> > > > It seems that in the next version when booting a container with
> > > > lxc-start, systemd creates a btrfs subvolume under
> > > > 
> > > >     rootfs/var/lib/machines
> > > > 
> > > > in every container. This will cause lxc-destroy for unprivileged
> > > > containers to
> > > > fail. (Because subvolumes can currently be created but not destroyed
> > > > by
> > > > unprivileged users.) There either needs to be a way to destroy btrfs
> > > > subvolumes
> > > > for unprivileged user with lxc-destroy or the creation of btrfs
> > > > subvolumes
> > > > during container boot needs to be prevented. Is the second option
> > > > already
> > > > available?
> > > > 
> > > > Best,
> > > > Christian
> > > 
> > > Add user_subvol_rm_allowed to your fstab and unprivileged users will be
> > > able to remove subvolumes.
> > 
> > I have user_subvol_rm_allowed set. But it will fail nonetheless.
> > lxc-destroy seems to expect that the rootfs is a btrfs subvolume.
> > However, if it sees that rootfs itself is simply a folder and not a
> > subvolume it will try to recursively delete it and then fail when it
> > encounters a subvolume within the rootfs.
> > (Systemd seems to create a btrfs subvolume only when the rootfs is a
> > simple folder.) I think there should be some way of making lxc-destroy
> > destroy all btrfs subvolumes within rootfs no matter if it is itself a
> > subvolume or a simple folder. Sorry, this wasn't clear in my first mail.
> 
> Ugh.  I guess patch for that would be welcome, though the safety of
> that in case of a misconfigured privileged container worries me.  But
> we can only protect that user from himself so much...
>

The problem is pretty annoying actually and it will probably soon affect Fedora
22, Archlinux (and Ubuntu Vivid?). I'm running an Archlinux host with systemd
219 which was officially released yesterday. This is taken from the systemd 219
announce:
(http://lists.freedesktop.org/archives/systemd-devel/2015-February/028447.html)

    * tmpfiles gained support for a new "v" line type for creating
      btrfs subvolumes. If the underlying file system is a legacy
      file system, this automatically degrades to creating a
      normal directory. Among others /var/lib/machines is now
      created like this at boot, should it be missing.

This means that systemd 219 will create a subvolume when the container's rootfs
is a btrfs subvolume. Here exemplified on two containers ("arch", "image")
running Archlinux with systemd 219 inside:

    [chb at conventiont ~]$ sudo btrfs subvolume list /
    ID 257 gen 92117 top level 5 path @
     D 1465 gen 91684 top level 257 path home/chb/.local/share/lxc/image/rootfs
    ID 1466 gen 91244 top level 1465 path home/chb/.local/share/lxc/image/rootfs/var/lib/machines
    ID 1459 gen 92126 top level 257 path home/chb/.local/share/lxc/arch/rootfs
    ID 1467 gen 92126 top level 1459 path home/chb/.local/share/lxc/arch/rootfs/var/lib/machines

This now means that lxc-destroy will fail when the rootfs is a btrfs subvolume
which contains a btrfs subvolume itself.
(Or can lxc-destroy currently destroy rootfs which are btrfs subvolumes which
contain subolumes themselves? If not it seems it should soon. But I'm
definitely not acquainted enough with the lxc codebase to implement this.)

Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150217/e4babeff/attachment.sig>