關於在新創建的掛載命名空間內掛載和解除安裝繼承的掛載

實驗一

從命名空間之外，cat /proc/self/mountinfo給出

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

然後我執行unshare -mU --map-root-user --propagation private /usr/bin/zsh在命名空間內獲取一個新外殼，但在新創建的掛載命名空間內，我不能 umount /tmp/IMJUSTTMP，umount只是告訴我它沒有掛載。雖然我可以檢查新創建的掛載命名空間cat /proc/self/mountinfo，但它提供了私有掛載

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

那為什麼umount: /tmp/IMJUSTTMP: not mounted.當我嘗試/tmp/IMJUSTTMP在命名空間內解除安裝時會得到呢？

我正在使用 5.0.9-arch1-1-ARCH，帶有kernel.unprivileged_userns_clone = 1.

實驗二

之後unshare -mU --map-root-user --propagation private /usr/bin/zsh，嘗試創建 overlayfs 也失敗了。

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

將按預期成功，而以下所有內容都將permission denied進入命名空間。

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

我的粗略猜測

我發現了這兩個問題，在使用者命名空間中，為什麼不允許我重新掛載已掛載的文件系統？為什麼我不能在使用者命名空間內綁定掛載“/”？似乎因為我繼承了/tmp/IMJUSTTMP和/tmp掛載，所以即使我在新創建的掛載命名空間的擁有使用者命名空間中獲得了全部功能，我也無法解除安裝它們。

問題

誰能解釋這兩個實驗到底發生了什麼？是否有任何文件提到在掛載命名空間內掛載和解除安裝的詳細核心行為？這個核心送出中提到的“超級塊所有者”是什麼？為什麼我不能在使用者命名空間內綁定掛載“/”？?

是的 ：-）。這裡有三個不同的點。

實驗一：為什麼umount: /tmp/IMJUSTTMP: not mounted我嘗試umount /tmp/IMJUSTTMP進入命名空間時會得到？

http://man7.org/linux/man-pages/man7/mount_namespaces.7.html

掛載命名空間的限制

關於掛載命名空間，請注意以下幾點：

• 掛載命名空間具有所有者使用者命名空間。所有者使用者命名空間與其父掛載命名空間的所有者使用者命名空間不同的掛載命名空間被視為特權較低的掛載命名空間。
• 在創建特權較低的掛載命名空間時，共享掛載會減少為從屬掛載。（共享掛載和從屬掛載將在下面討論。）這確保了在特權較低的掛載命名空間中執行的映射不會傳播到特權更高的掛載命名空間。
• 來自更高權限的掛載作為單個單元的掛載被鎖定在一起，並且不能在權限較低的掛載命名空間中分開。（unshare(2) CLONE_NEWNS 操作將原始掛載命名空間中的所有掛載作為一個單元，而在掛載命名空間之間傳播的遞歸掛載作為一個單元傳播。）
• mount(2) 標誌 MS_RDONLY、MS_NOSUID、MS_NOEXEC 和“atime”標誌（MS_NOATIME、MS_NODIRATIME、MS_RELATIME）設置在從特權更高的掛載命名空間傳播到特權較低的掛載命名空間時會被鎖定，並且不能在較少特權的掛載命名空間。

實驗 2：嘗試創建一個 overlayfs 也失敗了

嘗試使普通使用者的掛載操作安全​​並不是什麼新鮮事。LWN涵蓋了 2008 年的一個更新檔集。這項工作從未合併，但在 2015 年，當 Eric Biederman（以及其他人，特別是 Seth Forshee）認真考慮允許使用者命名空間執行文件系統掛載時，允許非特權掛載的努力得到了加強. 最初的工作 是在 2016 年為 4.8 核心合併的，但眾所周知，這不是問題的完整解決方案，因此大多數文件系統仍然只能由在初始命名空間中具有特權的使用者掛載。

非特權文件系統掛載，2018 版，LWN.net

2008 LWN 文章說，已被驗證為“在使用者命名空間中安全使用”的文件系統被標記為FS_USERNS_MOUNT. 所以我們可以很容易地搜尋到哪些文件系統是允許的。

這個核心送出中提到的“超級塊所有者”是什麼，以及“為什麼我不能在使用者命名空間內綁定掛載”/“？” ?

您連結到的核心送出中的原始碼表示，每個超級塊都被視為由特定的使用者命名空間擁有。所有者是最初創建超級塊的使用者命名空間。

引用自：https://unix.stackexchange.com/questions/517317