Messages in this thread | | | Date | Mon, 16 May 2005 12:26:48 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH] namespace.c: fix bind mount from foreign namespace |
| |
Miklos Szeredi wrote: > 1) you need not recursively bind the whole tree of the private > namespace. In fact you can only do that by hand, since the kernel > won't do it (!recurse || check_mnt(old_nd.mnt) in do_loopback).
That would be easy to change if it was desired though, by taking both namespace semaphores when two namespaces are involved.
> 2) you won't see changes made in other namespace, they are still > separate, they are just sharing some filesystems, just as after > clone, or just as after propagation within a shared subtree.
That's true.
Let's not get confused between binding across namespaces, and chroot/chdir into an fd supplied by a process from another namespace.
In the case of bind mount, that _won't_ see changes made in the other namespace. The /dentry/ visible in the other namespace is simply mounted here. The fact that it happens to come from another namespace is irrelevant: the other namespace is not used for single dentry bind mounts.
In the case of chroot/chdir, that _will_ see changes made in the other namespace. Effectively, that transitions into the other namespace as a whole, which is exactly what we want in some cases (when userspace policy determines that a per-session namespace is wanted).
> 4) in fact, the process in the originating namespace can single out a > mount and just send a file descriptor refering to that mount > (e.g. by binding it to a temporary directory, opening the root, > detaching from the mountpoint, and then sending the file descriptor > to the receiving process). This way the receiving process will see > no other mounts in the originating namespace, and can only bind > from that single mount.
Nice. The process in the originating namespace can also bind a small, carefully selected tree of mounts to a tree in that temporary directory before passing it, so the recipient can chroot/chdir into the set of mounts and get only those explicitly authorised by the originating process.
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |