Re: [PATCH] namespace.c: fix bind mount from foreign namespace

[Jamie Lokier]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/