[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux's future: //posix/ipc, //root and so on ?

    On Tue, 29 Feb 2000, Alexander Viro wrote:

    > On Wed, 1 Mar 2000, Khimenko Victor wrote:
    > > > Sigh... 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

    > 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.023 / U:44.404 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site