mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Biederman" <ebied...@xmission.com>
Subject Re: Review Request 13040: cgroup_isolator: Isolate the executors in their own mount namespace.
Date Wed, 31 Jul 2013 06:49:31 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message