[9fans] 1/2 OT: per-process mounts/namespace @ Linux

[9fans] 1/2 OT: per-process mounts/namespace @ Linux

[Enrico Weigelt]

Hi folks,


I was just reading some older mails on this list and thinking
about how to mimic the plan9 behaviour of local namespaces on
Linux. My idea is:

* each namespace is just some directory, ie. living somewhere
  under /.NAMESPACES/, maybe /.NAMESPACES/<pid>/
* these namespaces are maintained by either some daemon or
  an special synthetic filesystem
* processes with private namespaces are chroot()'ed to their
  own namespace directory.


What do you think about this ?


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[Eric Van Hensbergen]

Linux actually has private namespaces, its just off by default.  There
is a flag to clone which can be used to establish new processes in
private namespaces (CLONENS or some such thng).

Primary downside is that its superuser only -- but you could get
around it with setuid or custom kernel.

             -eric


On 9/7/07, Enrico Weigelt <weigelt@metux.de> wrote:
>
> Hi folks,
>
>
> I was just reading some older mails on this list and thinking
> about how to mimic the plan9 behaviour of local namespaces on
> Linux. My idea is:
>
> * each namespace is just some directory, ie. living somewhere
>   under /.NAMESPACES/, maybe /.NAMESPACES/<pid>/
> * these namespaces are maintained by either some daemon or
>   an special synthetic filesystem
> * processes with private namespaces are chroot()'ed to their
>   own namespace directory.
>
>
> What do you think about this ?
>
>
> cu
> --
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT service - http://www.metux.de/
> ---------------------------------------------------------------------
>  Please visit the OpenSource QM Taskforce:
>         http://wiki.metux.de/public/OpenSource_QM_Taskforce
>  Patches / Fixes for a lot dozens of packages in dozens of versions:
>         http://patches.metux.de/
> ---------------------------------------------------------------------
>

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On 9/7/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
> Linux actually has private namespaces, its just off by default.  There
> is a flag to clone which can be used to establish new processes in
> private namespaces (CLONENS or some such thng).
>
> Primary downside is that its superuser only -- but you could get
> around it with setuid or custom kernel.
>
>              -eric
>
>
Then you have to worry about what happens when people do things like binding
over /etc/passwd :-)

[-- Attachment #2: Type: text/html, Size: 934 bytes --]

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[Charles Forsyth]

> Then you have to worry about what happens when people do things like binding
> over /etc/passwd :-)

no, you need to worry why that is still there.

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[Latchesar Ionkov]

The simple solution would be to disable setuid/setgid flags for
private namespaces of users other than root. And then (not so simple)
fix programs
that don't work :)

   Lucho


On 9/7/07, David Leimbach <leimy2k@gmail.com> wrote:
>
>
> On 9/7/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> > Linux actually has private namespaces, its just off by default.  There
> > is a flag to clone which can be used to establish new processes in
> > private namespaces (CLONENS or some such thng).
> >
> > Primary downside is that its superuser only -- but you could get
> > around it with setuid or custom kernel.
> >
> >              -eric
> >
> >
>
> Then you have to worry about what happens when people do things like binding
> over /etc/passwd :-)
>
>
>
>

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[Eric Van Hensbergen]

There has been extensive discussion of multiple options here -- the
least of which is the paper I presented at OLS a few years back (Glen
or Glenda: http://citeseer.ist.psu.edu/vanhensbergen05glen.html).
There's an approachable list of safeguards.  Of course, if its your
desktop, you probably don't care to implement any of them...

    -eric


On 9/7/07, Latchesar Ionkov <lucho@gmx.net> wrote:
> The simple solution would be to disable setuid/setgid flags for
> private namespaces of users other than root. And then (not so simple)
> fix programs
> that don't work :)
>
>    Lucho
>
>
> On 9/7/07, David Leimbach <leimy2k@gmail.com> wrote:
> >
> >
> > On 9/7/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> > > Linux actually has private namespaces, its just off by default.  There
> > > is a flag to clone which can be used to establish new processes in
> > > private namespaces (CLONENS or some such thng).
> > >
> > > Primary downside is that its superuser only -- but you could get
> > > around it with setuid or custom kernel.
> > >
> > >              -eric
> > >
> > >
> >
> > Then you have to worry about what happens when people do things like binding
> > over /etc/passwd :-)
> >
> >
> >
> >
>

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[ron minnich]

On 9/7/07, Latchesar Ionkov <lucho@gmx.net> wrote:
> The simple solution would be to disable setuid/setgid flags for
> private namespaces of users other than root. And then (not so simple)
> fix programs
> that don't work :)

There's the other usual nonsense, such as device inodes etc. It's not
just setuid. But it's all pretty easy to fix.

ron

Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux

[ron minnich]

On 9/7/07, David Leimbach <leimy2k@gmail.com> wrote:

> Then you have to worry about what happens when people do things like binding
> over /etc/passwd :-)

See all my old stuff from 2.0.36

rules: you can only make a private name space in /private
and, by definition, no special inode bits -- which was a feature to
me, I was ambivalent on the .u extensions.

I think that made it impossible to fake out the usual stuff.

ron