From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 08 Oct 2003 - 20:15:16 BST
On Wed, Oct 08, 2003 at 01:40:07PM +0200, Enrico Scholz wrote:
> herbert_at_13thfloor.at (Herbert Poetzl) writes:
>
> >> > > Using this new system call, chmod 000 is not needed anymore
> >> > > and we can support vservers inside vservers.
> >> > why don`t use private namespace ?
> >>
> >> How does it work ?
> >
> > you should join a discussion with Enrico and me on IRC
> > .. basically it is based on CLONE_NEWNS() and relatives ...
>
> IMO, it is not doable with current technology:
>
> * CLONE_NEWNS has strange behavior[1]; this will be fixed[2] in
> 2.4.23 probably
>
> * CLONE_NEWNS + pivot_root are requiring CAP_SYS_ADMIN (which
> is not acceptably for vservers); using a new capability for
> CLONE_NEWNS seems to be possible, but pivot_root(2) needs
> additional logic. Else, when executed in root-namespace,
> pivot_root(2) can do really bad things with your system.
>
> * joining foreign namespaces (e.g. for 'vserver ... enter') is
> not implemented in current kernel; I saw patches but AFAIS,
> they are missing important logic (e.g. no capability-check).
> This functionality will need hierarchical contextes also
> (e.g. parent-vserver can enter namespace of child-vservers,
> but not this of if siblings or parents).
guess the pivot_root approach will take 1-2 further
kernel releases, but we will investigate this stuff
as it sounds very promising (hey, I suggested it half
a year ago ;)
the capability issues can be resolved by vserver
specific capabilities, which we'll probably introduce
in one of the next releases, anyway ...
best,
Herbert
> Enrico
>
> Footnotes:
> [1] http://www.tu-chemnitz.de/~ensc/nst.c
>
> [2] http://linux.bkbits.net:8080/linux-2.4/diffs/fs/namespace.c_at_1.24?nav=index.html|ChangeSet_at_-1d|cset_at_1.1182|hist/fs/namespace.c
> _______________________________________________
> Vserver mailing list
> Vserver_at_lists.tuxbox.dk
> http://lists.tuxbox.dk/mailman/listinfo/vserver