Open Stack

On Fri, Jul 11, 2014 at 09:53:47AM -0400, Eric Windisch wrote:
> >
> >
> > > Actually, there's a hidden assumption here that makes this statement not
> > > necessarily correct for containers.  You're assuming the container has
> > > to have raw access to the device it's mounting.  For hypervisors, this
> > > is true, but it doesn't have to be for containers because the mount
> > > operation is separate from raw read and write so we can allow or deny
> > > them granularly.
> >
> 
> I agree that a container does not have to have raw access to a device that
> it is mounting, but I also believe that the right contract for Cinder
> support is to expose raw access to those devices into containers. I don't
> believe that Cinder support should imply an ability to support mounting the
> arbitrary filesystems that might live on those volumes, just as we do not
> today require the guest OS on KVM, VMware, or Xen to support mounting any
> arbitrary filesystem that might live on a Cinder volume.
> 
> It might be stretching the contract slightly to say that containers cannot
> currently support ANY of the potential filesystems we might expect on
> Cinder volumes, but I really don't think this should be an issue or point
> of contention.  I'll remind everyone, too, that raw access to volumes
> (block devices) inside of containers is not a useless exercise. There are
> valid things one can do with a block device that have nothing to do with
> the kernel's ability to mount it as a filesystem.
> 
> I believe that for the use-case Cinder typically solves for VMs, however,
> containers folks should be backing a new filesystem-as-a-service API. I'm
> not yet certain that Manila is the right solution here, but it may be.
> 
> Finally, for those that do ultimately want the ability to mount from inside
> containers, I think it's ultimately possible. There are ways to allow safer
> mounting inside containers with varying trade-offs. I just don't think it's
> a necessary part of the Nova+Cinder contract as it pertains to the
> capability of the guest, not the capability of the hypervisor (in a sense).

Cinder can easily be used to provide filesystems to the container,
rather than block devices. There are patches pending for Libvirt LXC
which allow booting of the container from a root filesystem that is
backed by a cinder volume. The cinder volume is, however, mounted
in host context. Thus the container never sees the raw block device
and never has the ability to craft malicious filesystem structures
to exploit kernel bugs I mentioned before. This could easily be
extended to work for non-root filesystems too - all that is required
is an extra field to associated with the block device mapping which
specifies the container mount point. The host mgmt layer would be
responsible for all mkfs / mount operations, so the container never
need be exposed to block devices, and still make full use of features
that cinder provides.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|