Re: DoS with unprivileged mounts

From: Andy Lutomirski
Date: Thu Aug 15 2013 - 02:52:38 EST

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at