bind mounting namespace inodes for unprivileged users
Eric W. Biederman
ebiederm at xmission.com
Wed May 4 14:38:03 UTC 2016
James Bottomley <James.Bottomley at HansenPartnership.com> 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