On Tue, Nov 25, 2014 at 09:27:28AM +0100, Cedric Bosdonnat wrote:
On Tue, 2014-11-25 at 08:48 +0100, Martin Kletzander wrote:
> On Mon, Nov 24, 2014 at 09:54:46PM +0100, Cédric Bosdonnat wrote:
> >The typical case where we had a problem is with such a filesystem
> >definition as created by virt-sandbox-service:
> >
> > <filesystem type='bind' accessmode='passthrough'>
> > <source dir='/var/lib/libvirt/filesystems/mysshd/var'/>
> > <target dir='/var'/>
> > </filesystem>
> >
> >In this case, we don't want to unmount the /var subtree or we may
> >loose the access to the source folder.
>
> I probably didn't quite get this. This is only true when host root is
> the root of the container, isn't it? And in that case it doesn't make
> much sense to do this.
Indeed that happens when the host root is mounted as the container
root... and that's what virt-sandbox-service does. We have this
situation when the libvirt-sandbox service has a disk image:
* The disk image is mounted to /var/lib/libvirt/filesystems/<name>
* Quite a few items from /var/lib/libvirt/filesystems/<name> are
bind mounted to their equivalent in the container root, and /var is
one of them.
OK, and the mount below is done in the namespace of the container and
since we drop CAP_SYS_ADMIN, we're safe from the guest unmounting the
filesystem.
We can't handle this in case of circular dependencies and I guess it
doesn't make sense to even check for it. It will just fail anyway.
So ACK, thanks for the explanation.
Martin