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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list