bind mounting namespace inodes for unprivileged users

Eric W. Biederman ebiederm at
Wed May 4 14:38:03 UTC 2016

James Bottomley <James.Bottomley at> writes:

> Right at the moment, unprivileged users cannot call mount --bind to
> create a permanent copy of any of their namespaces.  This is annoying
> because it means that for entry to long running containers you have to
> spawn an undying process and use nsenter via the /proc/<pid>/ns files.
> The first question is:  assuming we restrict it to bind mounting only
> nsfs inodes, is there any reason an unprivileged user shouldn't be able
> to bind a namespace they've created to a file they own in the initial
> mount namespace?

Own, have read/write and unlink privileges.

My big concern would be the fact that a bind mount today makes a file
immune from unlink.  So it would mess up rm -rf.

That might not be worse than what a setuid fuse mount binary allows

I wonder if there might is a way to setup a
user namespace and mount namespace combination so users could manage
mounts in their own login shells, just like is allowed in plan 9.
Long term I think that would be more satisfactory.

> So, does anyone have any strong (or even weak) opinions about this
> before I start coding patches?

The mount namespace is complex and getting it right is a pain in the
rear.  So adding yet another path and piece in to the existing
complexity makes me cringe a little.


More information about the Containers mailing list