Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 14 Nov 2013 17:38:48 -0800 | Subject | Re: [PATCH] userns: allow privileged user to operate locked mount |
| |
Gao feng <gaofeng@cn.fujitsu.com> writes:
> On 11/15/2013 07:50 AM, Eric W. Biederman wrote: >> Gao feng <gaofeng@cn.fujitsu.com> writes: >> >>> Privileged user should have rights to mount/umount/move >>> these even locked mount. >> >> Hmm. This is pretty much a can't happen case, as the only exist in mount >> namespaces where the global root isn't the root. How are you getting >> into this situation? Using setns() ? >> > > Before, priviged user can use setns to set his mount namespace to the > container's mount namespace, and change container's mount directly. > this patch just gives back host the control of container.
Having thought about this patch a little more I really don't like it.
There are other ways for a privileged user to get around the limitations when the mount namespace is being created or the mounts are being propagated.
This approach would require more then a signgle bit of accounting to work in the nested user namespace case.
The lock says one or several mounts are mounted as a unit and need to stay that way.
If there are real advantages to splitting things up I might be persuaded to change my mind. But right now it looks like you are introducing extra complexity for a very corner edge case that we don't want to encourage people to use.
Eric
| |