[lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail
> 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@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
pgpIASheaJygX.pgp
Description: PGP signature
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail
Quoting Christian Brauner (christianvanbrau...@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... ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail
> 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. Christian pgpwq07Qum6rW.pgp Description: PGP signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail
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. > > From the man page of machinectl: > (http://man7.org/linux/man-pages/man1/machinectl.1.html) > FILES AND DIRECTORIES top > >Machine images are preferably stored in /var/lib/machines/, but are >also searched for in /usr/local/lib/machines/ and > /usr/lib/machines/. >For compatibility reasons the directory /var/lib/container/ is >searched, too. Note that images stored below /usr are always >considered read-only. It is possible to symlink machines images > from >other directories into /var/lib/machines/ to make them available > for >control with machinectl. > ___ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail
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 From the man page of machinectl: (http://man7.org/linux/man-pages/man1/machinectl.1.html) FILES AND DIRECTORIES top Machine images are preferably stored in /var/lib/machines/, but are also searched for in /usr/local/lib/machines/ and /usr/lib/machines/. For compatibility reasons the directory /var/lib/container/ is searched, too. Note that images stored below /usr are always considered read-only. It is possible to symlink machines images from other directories into /var/lib/machines/ to make them available for control with machinectl. pgp0EfUpn3ZYZ.pgp Description: PGP signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
