6

Experiment 1

From outside the namespace, cat /proc/self/mountinfo gives

291 34 0:37 / /tmp/IMJUSTTMP rw,relatime shared:152 - tmpfs tmpfs rw,size=102400k
34 23 0:32 / /tmp rw,nosuid,nodev shared:16 - tmpfs tmpfs rw

Then I run unshare -mU --map-root-user --propagation private /usr/bin/zsh to get a new shell inside a namespace, but inside the newly-created mount namespace, I can't umount /tmp/IMJUSTTMP, umount just tell me it's not mounted. While I can check the newly-created mount namespace by cat /proc/self/mountinfo, which gives private mount 

290 263 0:32 / /tmp rw,nosuid,nodev - tmpfs tmpfs rw
302 290 0:37 / /tmp/IMJUSTTMP rw,relatime - tmpfs tmpfs rw,size=102400k

Then why do I get umount: /tmp/IMJUSTTMP: not mounted. when I try to umount /tmp/IMJUSTTMP inside the namespace?

I'm using 5.0.9-arch1-1-ARCH, with kernel.unprivileged_userns_clone = 1.

Experiment 2

After unshare -mU --map-root-user --propagation private /usr/bin/zsh, trying to create an overlayfs also fail.

mkdir -p /tmp/IMJUSTTMP/work
mkdir /tmp/IMJUSTTEST
mount -t tmpfs -o size=100m tmpfs /tmp/IMJUSTTMP
mount -t tmpfs -o size=200M tmpfs /tmp/IMJUSTTEST

Will all succeed as expected, While all the following would get permission denied inside the namespace.

mount -t overlay -o "lowerdir=/home/xtricman,upperdir=/tmp/IMJUSTTMP/,workdir=/tmp/IMJUSTTMP/work" overlay /home/xtricman
mount -t overlay -o "lowerdir=/tmp/IMJUSTTEST,upperdir=/tmp/IMJUSTTMP,workdir=/tmp/IMJUSTTMP/work" overlay /mnt

Rough Guess of mine

I found these two questions, Inside a user namespace, why am I not allowed to remount a filesystem I have mounted? and Why can't I bind-mount "/" inside a user namespace? It seems that since I inherit the /tmp/IMJUSTTMP and /tmp mount, so I can't umount them even if I got full capabilities in the owning user namespace of the newly-created mount namespace.

Question

Can anyone explain what exactly what's going on of the two experiments? Is there any document mentioning detailed kernel behavior of mounting and umounting inside a mount namespace? What is the "superblock owner" as mentioned in this kernel commit and Why can't I bind-mount "/" inside a user namespace? ?

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
炸鱼薯条德里克
  • 1,337
  • 1
  • 12
  • 31
  • Have you tried with `umount -f` ? – Stephen Harris May 06 '19 at 02:44
  • @StephenHarris I repeat the experiment, get wierder result. `umount /tmp/IMJUSTTMP` and `umount /tmp/IMJUSTTMP -f` both give `umount: /tmp/mountinfo: no mount point specified.` and don't umount that mount point. I double checked `/proc/self/mountinfo`, that mountpoint really exist inside the newly-created mount namespace. – 炸鱼薯条德里克 May 06 '19 at 02:54

1 Answers1

4

Yes :-). There are three distinct points here.

Experiment 1: Why do I get umount: /tmp/IMJUSTTMP: not mounted when I try to umount /tmp/IMJUSTTMP inside the namespace?

mount_namespaces(7)

[...]

Restrictions on mount namespaces

Note the following points with respect to mount namespaces:

  1. Each mount namespace has an owner user namespace. As explained above, when a new mount namespace is created, its mount list is initialized as a copy of the mount list of another mount namespace. If the new namespace and the namespace from which the mount list was copied are owned by different user namespaces, then the new mount namespace is considered less privileged.

  2. When creating a less privileged mount namespace, shared mounts are reduced to slave mounts. This ensures that mappings performed in less privileged mount namespaces will not propagate to more privileged mount namespaces.

  3. Mounts that come as a single unit from a more privileged mount namespace are locked together and may not be separated in a less privileged mount namespace. (The unshare(2) CLONE_NEWNS operation brings across all of the mounts from the original mount namespace as a single unit, and recursive mounts that propagate between mount namespaces propagate as a single unit.)

[...]

Experiment 2: Trying to create an overlayfs also fails

Unprivileged filesystem mounts, 2018 edition [LWN.net]

Attempts to make the mount operation safe for ordinary users are nothing new; LWN covered one patch set back in 2008. That work was never merged, but the effort to allow unprivileged mounts picked up in 2015, when Eric Biederman (along with others, Seth Forshee in particular) got serious about allowing user namespaces to perform filesystem mounts. The initial work was merged in 2016 for the 4.8 kernel, but it was known to not be a complete solution to the problem, so most filesystems can still only be mounted by users who are privileged in the initial namespace.

The 2008 LWN article says filesystems that have been verified as "safe for use within user namespaces" are flagged as FS_USERNS_MOUNT. So we can easily search to find which filesystems are allowed.

Note that this flag has been added to the OverlayFS with kernel version 5.11. Hence you can now mount one inside a privileged user and mount namespace.

What is the "superblock owner" as mentioned in this kernel commit and the question "Why can't I bind-mount "/" inside a user namespace?" ?

The source code in the kernel commit you link to, says that each superblock is considered owned by a specific user namespace. The owner is the user namespace which originally created the superblock.

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
  • Ok, the single unit thing seems to explain the result of Experiment 1, but could you explain the result of Experiment 2? According to what you said, can I say, as long as I have CAP_SYS_ADMIN in the owner user namespace of that super block, I can change super-block mount options? – 炸鱼薯条德里克 May 06 '19 at 10:14
  • @炸鱼薯条德里克 thanks, edited, please reread :-). – sourcejedi May 06 '19 at 11:31
  • Michael Kerrisk obviously has edited the man page and fixed the misleading first item about "parent mount namespace[s]". As all namespace types are flat, except for user and PID namespaces, there aren't any parent mount namespaces. Instead, the newly created mount namespace is a copy of the mount namespace active when a process calls unshare or clone, but the owning user namespace of the new mount namespace always is the currently active user namespace. – TheDiveO Jan 28 '21 at 19:58
  • What is a "less privileged mount namespace"? Is it a mount namespace that branches off from another? Is it a mount namespace owned by an unprivileged user namespace? – Melab Dec 31 '22 at 12:57
  • @Melab I've updated to match the man page as pointed out by TheDiveO. And as they said, "the owning user namespace of the new mount namespace is always the currently active user namespace". Hopefully this answers your question. – sourcejedi Dec 31 '22 at 22:57