Gao feng <gaofeng@xxxxxxxxxxxxxx> writes: > On 11/15/2013 07:50 AM, Eric W. Biederman wrote: >> Gao feng <gaofeng@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
