Why am I able to mount arbitrary TMPFS as an unprivileged user with unshare?

Question

While messing around with unshare, I stumbled on the following behavior in an unprivileged shell:

foo@pc $ id foo
uid=1000(foo) gid=1000(foo) groups=1000(foo),27(video),97(input)

foo@pc $ unshare -r -m bash
root@pc # mkdir /tmp/somedir
root@pc # mount -t tmpfs -o size=50M none /tmp/somedir
root@pc # mount | grep somedir
none on /tmp/somedir type tmpfs (rw,relatime,size=51200k,uid=1000,gid=1000)

I was surprised that mount actually worked, since it has been run with a "faked" root user due to the -r option of unshare.

This seems to happen only for TMPFS, trying to mount anything else seems to properly fail.

Also if I remove the -m option which preserves the parent's mount namespace, mounting fails as expected:

mount: /tmp/somedir: permission denied.

mount_namespaces(7) doesn't describe anything particular related to TMPFS.

Why was I able to mount that TMPFS while my real user id is an unprivileged one? Why does unsharing the mount namespace allows this mount?

This is on a x86_64 Gentoo, with a 4.19.27 Linux kernel.

Answer 1

That's not only a mount namespace – the -r option also causes a new user namespace to be created as well, as that's how UID mappings ("faked root") are really implemented.

$ strace unshare -r -m true
unshare(CLONE_NEWNS|CLONE_NEWUSER)      = 0

User namespaces by design give you some "root-like" privileges that are confined to that specific namespace; this is how Linux containers work. (In other words, your uid 0 isn't fake uid 0; it is real uid 0 of its own namespace that has full privileges in its own userns, just not in the parent userns.)

That includes the ability to mount certain filesystems (listed in the manual page), such as overlayfs or tmpfs, which support namespacing and might be necessary for containers to function. (In the future this might include even traditional disk filesystems, thanks to the "filesystem ID mapping" feature that went into kernel 5.12.)

Note that Linux only allows this within a mount namespace that is "owned" by the new uid 0. If you hadn't used the -m option but tried to mount something within the parent mount namespace, you still wouldn't have any privileges to do that.