On 5/12/05, Jamie Lokier <[email protected]> wrote:
> Eric Van Hensbergen wrote:
> > On 5/11/05, Jamie Lokier <[email protected]> wrote:
> > > Please read carefully: I've described what _current_ kernels do.
> > >
> >
> > I guess I misread when you wrote:
>
> There are some things which you can't do with current kernels due to
> the checks against current->namespace. I'm not sure how important
> those checks are. And there are some things which you _can_ do, such
> as passing directory file descriptors among processes which are in
> different namespaces.
>
I'm not sure passing directory file descriptors is the right semantic
we want - but at least it provides a point of explicit control (in
much the same way as a bind). Are you sure the clone + open("/") +
pass-to-parent scenario you allows the parent to traverse the child's
private name space through that fd? That seems as bad as accessing
pid name space via the /proc file system.
In Plan 9, file descriptors are passed between name spaces, but the
only use of such a facility (described in fork(2) [plan9man]) is to
pass channels to file servers which can then be mounted in a blank
name space. exportfs(4)[plan9man] seems to provide a much nicer
semantic for this sort of name space sharing.
Let's focus on baby steps first, and to me that's:
a) get rid of holes that allow users to traverse out of a chroot jail
by using the creation of private name spaces (is anyone working on
this, did I miss a patch?)
b) make CLONE_NEWNS (and any other name space creation mechanisms such
as the proposed unshare system call) available to normal users
c) Get the unshare system call adopted as it seems to be generally useful
d) Get Miklos' unprivileged mount/umount patch adopted in mainline
These 4 things open up lots of opportunities and alternatives, if they
prove to be insufficient then we can press forward on name spaces as
first class objects, etc.
-eric
[plan9man] Plan 9 manual pages are available at
http://plan9.bell-labs.com/sys/man/index.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]