I don't see why should we do tricks like that. We have support for private namespaces, why should we make the linux code even more complicated?
Thanks, Lucho On Monday, July 13, 2009, Tim Newsham <news...@lava.net> wrote: > > Could we solve this by making private mounts the default (or only > allowed) behavior? > > > I've wondered if there's enough context information > that the fs driver could "fake" per-process mount points > directly. For example, I mount v9fs on /n. Initially > I have no remote mounts in there, but I have /n/ctl. > I echo "mount 1.2.3.4 foo" to /n/ctl and now I have > /n/foo which is served from 1.2.3.4 for my process, but > other processes dont see /n/foo. I fork a child and it > gets /n/foo, too. In the child I mount another directory > and the changes are seen in both the child and the parent. > I then echo "copyns" to /n/ctl and then perform another > mount and the new mount is visible in the child process but > not the parent process. > > This would of course require that the kernel filesystem > (probably vfs layer) could distinguish who made a filesystem > request. It might also require some hackery to get the > inheritance on fork working properly (although perhaps some > existing unix mechanism could be reused for this purpose, such > as session and process group stuff). > > Feasible at all in Linux? *BSD? Win32? > > Upsides: Kernel doesnt need to otherwise support any notion > of mount namespace. Removes security concerns of per-process > namespaces since you could never rebind over /etc/passwd or > other important files. > > Downsides: Perhaps not possible. Mount/bind namespaces not > universally present, only within certain mount points. > > > ron > > > Tim Newsham > http://www.thenewsh.com/~newsham/ > >
