Re: [RCF] [PATCH] unprivileged mount/umount

Miklos Szeredi
2005-05-13T08:55:46Z

> I think the best thing to do for "jails" and such is to think of a
> private namespace as a collection of bind mounts in a private tree
> that (normally) cannot be reached from elsewhere, not can it reach
> elsewhere.
>
> And leave it to adminstration to ensure that a tree isn't visible from
> another tree if you don't want it to be for security purposes. That
> basically amounts to making sure processes that shouldn't communicate
> or ptrace each other can't.
>
> With that view, the kernel's notion of "namespace" is redundant.

I'm not sure.

> It doesn't add anything to the security model, and it doesn't add
> any useful functionality.

Struct namespace is pretty small, so let's see:

1) count: reference count for the "tree"

if you remove this, how will you know when to "unmount" the tree?

2) root: the root of the tree

needed for the unmount, when the namespace has no more references

3) list: flat list of mounts in the tree

used by /proc/PID/mounts, but probably not strictly needed

4) sem: protects the mount list and the tree from modification

could be removed in favor of a global lock, but that would
increase contention

> In other words, is ->mnt_namespace required at all, except to contain
> namespace->sem (which could be changed)? I don't think it adds
> anything realistic to security. The way to make secure jails is to
> isolated their trees so they are unreachable. ->mnt_namespace doesn't
> make any difference to that.

Probably true. check_mnt() is there to make sure only trees protected
by namespace->sem are modified, and is not a security check. That is
why the recursive bind mount from foreign namespace is not allowed,
while the simple bind mount is.

Miklos