> On July 30, 2013, 11:39 p.m., Vinod Kone wrote:
> > src/slave/cgroups_isolator.cpp, line 506
> > <https://reviews.apache.org/r/13040/diff/1/?file=330357#file330357line506>
> >
> >     Are these mount flags new? I couldn't find them on man mount(2) on  
> > CentOS 5 box with 2.6.44 kernel, though I did find them by searching online.

Yes.  As of 2.6.15.  It is weird I don't see the flags in mount(2).  They are 
semantically documented in mount(8) under mount --rprivate.

So even an unpatched RHEL 5 should support this.


> On July 30, 2013, 11:39 p.m., Vinod Kone wrote:
> > src/slave/cgroups_isolator.cpp, line 606
> > <https://reviews.apache.org/r/13040/diff/1/?file=330357#file330357line606>
> >
> >     I'm new to clone(), so just want to make sure the semantics are 
> > backwards compatible.
> >     
> >     We currently have executors that write outside the sandbox. Would this 
> > stop them from doing that?

This setup still allows writing outside of the sandbox.

By itself CLONE_NEWNS just creates a copy of the current set of mounts.  So 
everything stays the same. 

The advantage is that later we can change these mounts and not affect the rest 
of the system.  Unless mount shared subtrees are setup you can not affect the 
mounts of any other process.  The mount command is in case mesos-slave is 
running on a system with shared trees setup to guarantee our mounts don't 
propagate outside of our mount namespace.

There are manipulations like read-only bind mounts that we can use to guarantee 
you can only write in your sandbox but those are additional mount commands that 
need to be run.

There are also strong manipulations like pivot_root that can be used to use a 
different direction as /, and of course there is also unmount to remove mounts 
executors should not see.

But again I really don't take advantage of mount namespaces in this patch.  I 
just set them up so that in the future when we are ready we can take advantage 
of them.  The only immediate gain is if an executor with root privileges runs 
it can not mess with the mounts seen by anyone else.


- Eric


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13040/#review24275
-----------------------------------------------------------


On July 29, 2013, 10:22 p.m., Eric Biederman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13040/
> -----------------------------------------------------------
> 
> (Updated July 29, 2013, 10:22 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Ian Downes, and Vinod 
> Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> cgroup_isolator: Isolate the executors in their own mount namespace.
> 
> When starting an executor create a mount namespace and make the mounts
> private in the new namespace to prevent any changes in the mount
> namespace from propagating back to the original mount namespace.
> 
> This results in no change in visibility or accessibilty of files
> for the executor so this should not result in any regressions.
> 
> In addition to the initial small isolation effect this also prepares
> for using the mount namespace to remove the possibility of filesystem
> accesses that executors and tasks should not be able to perform.
> 
> 
> Diffs
> -----
> 
>   src/slave/cgroups_isolator.cpp 0faf7d5 
> 
> Diff: https://reviews.apache.org/r/13040/diff/
> 
> 
> Testing
> -------
> 
> make -j8 check
> 
> And watched the tests pass.
> 
> 
> Thanks,
> 
> Eric Biederman
> 
>

Reply via email to