Andrew Vagin <avagin@xxxxxxxxxxxxx> writes: > On Tue, Oct 07, 2014 at 01:58:01PM -0700, Eric W. Biederman wrote: >> Andrew Vagin <avagin@xxxxxxxxxxxxx> writes: >> >> > On Tue, Oct 07, 2014 at 12:27:06PM -0700, Eric W. Biederman wrote: >> >> >> >> Which in practice is totally uninteresting. Only the global root user can >> >> do it, and it is just a stupid thing to do. >> >> >> >> However that is no excuse to allow a silly way to oops the kernel. >> >> >> >> We can avoid this silly problem by setting MNT_LOCKED on the rootfs >> >> mount point and thus avoid needing any special cases in the unmount >> >> code. >> > >> > I had this idea too, but it doesn't work. >> > >> > MNT_LOCKED isn't inherited, if the privileged user creates a new mount >> > namespace. >> > >> > So "unshame -m ./nsenter" reproduces the same BUG. >> >> Which broken tree do you have where MNT_LOCKED is not inherited? > > It is Linus' tree with your patch. > > I commented out one line and the BUG isn't triggered any more. Ok. That is very very weird. It works for me and not for you. Doh! I ran your test program first on the primary mount namespace and didn't have /proc mounted when I tried to run your test program later. Thanks for the hint about copy_tree that does seem to be where the logic goes haywire. In copy_mnt_ns we want an exact copy not a partial copy. The good news is that this bug could only affect rootfs, so it is not a security hole with respect to mount namespaces, created with user namespace permissions. mount --rbind and mount propogation should not be locked to their parent mounts so we do need to clear MNT_LOCKED in a few places. A patch that fixes copy_tree carefully in a moment. 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
