On Tue, 29 Feb 2000, Alexander Viro wrote:
>
>
> On Wed, 1 Mar 2000, Khimenko Victor wrote:
>
> > > Sigh... http://inferno.bell-labs.com/plan9/vol2.html. Notice the stuff
> > > under "Namespaces". Authors: group of little-known BTL guys, some
> > > Thompson, Ritchie, Pike...
> > >
> > This is all great and flashy but I'm not sure if we can do somthing like
> > this without rewriting of each and every program in system. And I've not
> > found there answer on simple question: "how this all great picture will
> > keep up when old innocent unix program will call chroot("/home/username") ?"
>
> Read again. Hint: if no process does rfork() (== clone()) with the right
> flag (don't share namespace) they behave as on classical UNIX. Your
> program (and it's _not_ innocent if it plays with chroot - it should at
> the very least care about preparing the environment) should do
> namespace-splitting clone() and _mount_ (while it still has UID==0) ipcfs
> at /ipc.
It's thing like ftpd which expect that environment is there. Or similar
program to execure cgi script in sandbox. And without devfs, procfs and
ipcfs it's DOABLE: you can put all needed libraries as hardlinks
there. Without // trick (or rather /../ trick -- looks much saner to me)
it's doable as well. WITHOUT changes for each and every program when new
netfs or whjatever is implemented.
> After chroot, right. Nobody else will ever see the thing mounted
> there - namespace is exactly what builds a unified tree from the
> individual filesystems. On any UNIX. The whole idea is to make it a
> per-process resource. That can be shared or copied upon clone(), just as
> every other resource does (mm, descriptors, signals, etc. - it's hardly a
> new idea). Default (i.e. what fork() does) is unusual - it's share instead
> of copy. As on any UNIX - you have trees from individual filesystems and
> you know how they are glued into the unified tree. Just that idea of that
> gluing may be different for different sets of processes. It's _not_ an
> extensive change to our architecture. We need to scratch
> ->d_covers/->d_mounts and replace the logics regarding the crossing of
> mountpoints. We also need some trickery wrt sharing files across
> namespace-splitting clone() (esp. opened directories), but that's
> solvable. My main problem with doing full-blown namespaces is that I don't
> want to spend couple of months _after_ this change fixing nasty races.
> I'ld rather get dcache/namei into the robust form before that. And that's
> what made me seriously unhappy about devfs addition - it makes things
> trickier. Oh, well...
>
Namespaces ARE great. It's just orthogonal issue :-( The whole idea behind
superoot is to remove need to add ANYTHING to programs with chroot when
there are new wonderfull filesystem like procfs, devfs or ipcfs is
created.
> Victor, RTFManpages (on the same site) and look through our
> namespace-related code. It's not that horrible change. BTW, some ideas we
> got from there include: procfs, dcache and... devfs. Read their
> documentation through - we all owe those guys that much. Really. They had
> proven that they _have_ taste - basic API designed by them works 30 years
> later and is used by literally all living decent systems. That's something
> one can be proud of. Really. It's not about replacing everything with
> Plan 9 - I don't want it. But there are very good design ideas that fit
> well into UNIX semantics and were unclaimed since neither USL nor BSD
> branches had enough infrastructure in the kernel. WE HAVE IT. We have
> superior VFS design - best of all Unices I've seen or heard of. Thanks to
> the work of Linus, Bill Hawes, Schobel-Theuer and a lot of other people.
> We are in unique position - we can incorporate the good ideas of Plan 9
> _without_ dropping compatibility with UNIX. Something that was deemed
> inpractical by BTL folks, BTW. It would be a fscking shame if we blew it.
>
Namespaces are great. Just it solves COMPLETELY other problem then
superroot is designed to solve...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:09 EST