<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
</div>Why would you mount it from within the container?  CAP_SYS_ADMIN is a<br>
per process property, so you use nsenter to execute the mount in the<br>
required mount namespace with CAP_SYS_ADMIN from outside of the<br>
container (i.e. the host).  I assume this requires changes to cinder so<br>
it executes a mount rather than presenting a mountable device node, but<br>
it's the same type of change we have to do for mounts which have no<br>
node, like bind mounts.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div></div>-- <br><div dir="ltr">Regards,<div>Eric Windisch</div></div>
</div></div>