On Wed, Aug 14, 2013 at 11:45 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Miklos Szeredi <miklos@xxxxxxxxxx> writes: > >> On Wed, Aug 14, 2013 at 9:32 PM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >> >>>> The solution is also theoretically simple: mounts in unpriv namespaces >>>> are marked "volatile" and are dissolved on an unlink type operation. >>>> >>>> Such volatile mounts would be useful in general too. >>> >>> Agreed. >>> >>> This is a problem that is a general pain with mount namespaces in >>> general. >>> >>> I think the real technical hurdle is finding the mounts t in some random >>> mount namespace. Once we can do that relatively efficiently the rest >>> becomes simple. >> >> We already have a "struct mountpoint" hashed on the dentry. Chaining >> mounts on that mountpoint would be trivial. And we need a >> MNT_VOLATILE flag and that's it. If we fear that traversing the list >> of mounts on the dentry to check for non-volatile ones then we could >> also add a separate volatile counter to struct mountpoint and a >> matching flag to the dentry. But I don't think that's really >> necessary. > > *Blink* I had overlooked "struct mountpoint". That indeed makes things > easier. > > I agree we can chain "struct mount" on "struct mountpoint" and then we > would have an efficient implementation, that does not impact the vfs > fast path. > > After that it becomes a question of permissions and semantics. > > I am in the process of adopting the rule that something that is not > visible at the time we copy a set of mounts should not become visible > in the child mount namespace. Grr. This has been a busy month and > despite having been reviewed I haven't gotten around to pushing that > patch to linux-next. > > But MNT_VOLATILE by definition can not reveal anything becasue the > underlying mount point is removed, so that all of that weirdness is in > propogating mounts between mount namespaces is not relevant here. > > This is however the propogation of an unmount between mount namespaces. > > In general we don't even need the MNT_VOLATILE flag we just need the > appropriate permission checks. However we do need something like > MNT_VOLATILE to prevent surprises. MNT_VOLATILE would be used to > prevent things like: > > # mount --bind / /mnt > # rmdir /mnt/usr > > I think the root user would be rather annoyed if that worked, so it does > appear we need something like MNT_VOLATILE. > > Part of me does prefer the semantics Andy has suggested where instead of > unmounting things we have something like a skeleton of the mount tree > unioned with dcaches of the filesystems themselves. With "struct > mountpoint" we are amazing close to that already. Two possible nasty cases: 1. mount whatever /tmp/foo/bar; rmdir /tmp/foo/bar; rmdir /tmp/foo Presumably ls /tmp shouldn't show foo. Should cd /tmp/foo/bar work? What about umount /tmp/foo/bar? What about cd /tmp/foo? 2. mount whatever /tmp/foo; rmdir /tmp/foo; mkdir /tmp/foo Ugh. --Andy -- 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
