掛載命名空間 API 是否可以有效地變得多餘？會有什麼障礙？

1. 如果您有對它們的引用，您仍然可以訪問不同掛載命名空間中的文件和目錄。但是，目前您無法操作（甚至列出）掛載命名空間的掛載，如果它不是您正在執行的命名空間。
2. 分離的掛載 ( umount -l) 被認為沒有掛載命名空間，因此您不能操作它們（或列出子掛載）。

第 1 點（或第 2 點）的限制對於命名空間 API 是否必不可少，例如為了安全？它是否依賴於現有軟體？

如果沒有，是否很難從 Linux 程式碼中刪除第 2 點（和第 1 點）的限制？也就是說，這樣做的主要障礙是什麼？

動機：如果你可以創建分離的掛載樹，你可以chroot進入它們，我認為掛載命名空間大多是多餘的。儘管它們仍然會為其他類型的 Linux 命名空間提供一些便利/統一。

如果你可以建構一個分離的掛載樹，你可以chroot進入它，我認為掛載命名空間大多是多餘的。儘管它們仍然會為其他類型的 Linux 命名空間提供一些便利/統一。

我認為我錯過了（至少）一個重要的點。

命名空間的特性之一是它們與使用者命名空間相關聯。使用者命名空間隔離了“超級使用者”功能，例如 CAP_SYS_ADMIN 和 CAP_NET_RAW。例如，CAP_NET_RAW 可以允許訪問網路設備上的原始網路數據包 - 如果它們屬於屬於您的使用者的網路命名空間。

CAP_SYS_ADMIN 允許您操作屬於您的使用者的掛載命名空間。目前限制可能比嚴格要求的要嚴格，但您需要一些限制。將掛載樹綁定到命名空間是必要的，以便使用者命名空間可以隔離 CAP_MOUNT。

我想實現掛載命名空間的替代方法沒有多大意義，因為它不適用於使用者命名空間。

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