Open Stack

>
>
> Why would you mount it from within the container?  CAP_SYS_ADMIN is a
> per process property, so you use nsenter to execute the mount in the
> required mount namespace with CAP_SYS_ADMIN from outside of the
> container (i.e. the host).  I assume this requires changes to cinder so
> it executes a mount rather than presenting a mountable device node, but
> it's the same type of change we have to do for mounts which have no
> node, like bind mounts.
>

It's a matter of API adherence. You're right, however, another option for
this etherpad is, "extend the API". We could add an extension to OpenStack
that allows the host to initiate a mount inside an instance.  That isn't
much different than the existing suggestion of a container-level API for
speaking back to the host to initiate a mount, other than this suggestion
being at the orchestration layer, rather than at the host-level.

In part, this discussion and the exercise of writing this etherpad is to
explore alternatives to "this isn't a valid use-case".  At a high-level,
the alternatives seem to be to have an API the containers can use speak
back to the host to initiate mounts or finding some configuration of the
kernel (possibly with new features) that would provide a long-term solution.

I'm not fond of an API based solution because it means baking in
expectations of a specific containers-service API such as the Docker API,
or of a specific orchestration API such as the OpenStack Compute API. It
might, however, be a good short-term option.

Daniel also brings up an interesting point about user namespaces, although
I'm somewhat worried about that approach given that we can exploit the host
with crafty filesystems. It had been considered that we could provide
configurations that only allow FUSE. Granted, there might be some
possibility of implementing a solution that would limit containers to
mounting specific types of filesystems, such as only allowing FUSE mounts.

-- 
Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/b650f996/attachment.html>