為什麼可以使用使用者命名空間在沒有真正根的情況下創建其他命名空間？
使用該命令
unshare創建命名空間時，如果你不是宿主機的 root 並且創建除了使用者類型之外的任何命名空間，你會收到這個錯誤：Operation not permitted.顯然，以 root 身份執行將使其工作。那麼，如果
unshare -n(unshare the network namespace) 給出了這個錯誤，為什麼unshare -Un(unshare the user and the network namespace) 沒有呢？我看到但不知道是否正確的第一個選項是所有名稱空間實際上都與使用者名稱空間相關聯。如果您沒有足夠的權限，則無法將新的命名空間與其關聯。但是，當您創建使用者命名空間時，您將獲得權限，這成為可能。
如果上述情況屬實，我可以說每個程序都有一個使用者命名空間，即使我從未明確地將它創建為使用者？這適用於其他名稱空間嗎？
編輯：正如評論中所指出的，
unshare -Un可能會給出同樣的錯誤：operation not permitted. 我正在使用啟用了使用者命名空間的 Ubuntu 20.04 進行測試。我相信這就是區別。
因為為什麼不呢？
命名空間是一種沙盒機制。它們允許在隔離域內修改某些設置，而不必擔心它們是否會影響系統的其餘部分。
以掛載命名空間為例。掛載文件系統通常是一項特權操作：如果您可以掛載任意文件系統，您尤其可以掛載包含您選擇的 set-user-id 執行檔的文件系統，然後執行它，從而執行權限提升攻擊。但是，在使用者命名空間內啟動 set-user-id 執行檔只能增加其在該命名空間內的權限：使用者命名空間內的根使用者 ID 將映射到命名空間外的正常使用者 ID，並且程序功能同樣僅適用於資源從屬於該命名空間。
如果沒有使用者命名空間，創建其他類型的命名空間可能會被用於以類似方式提升權限。但是當“特權”被限制在使用者命名空間中時，沒有理由再不允許它了——事實上，有一些案例可以做到這一點。使用者命名空間不僅限制特權，而且還創造了在命名空間內定義特權-非特權邊界的可能性，防止流氓程序完全逃離沙箱並接管沙箱本身。
LWN 文章Namespaces in operation, part 6: more on user namespaces列出了一些可能的非特權創建命名空間的應用程序：
通過隔離功能對命名空間的影響，使用者命名空間兌現了安全地允許非特權使用者訪問以前僅限於 root 使用者的功能的承諾。這反過來又為新型使用者空間應用程序創造了有趣的可能性。例如，現在非特權使用者可以在沒有 root 權限的情況下執行 Linux 容器，在不使用 set-user-ID-root 幫助程序的情況下建構Chrome 風格的沙箱，在不使用動態連結技巧的情況下實現fakeroot類型的應用程序，並實現
chroot()基於應用程序用於程序隔離。除了核心錯誤，使用使用者命名空間來訪問特權核心功能的應用程序比基於 set-user-ID-root 的傳統應用程序更安全：使用基於使用者命名空間的方法，即使應用程序受到攻擊，它也沒有任何可用於在更廣泛的系統中造成損害的特權。也就是說，增加對使用者命名空間的支持本身就為 Linux 引入了許多安全漏洞（僅舉一個例子），以至於某些發行版預設禁用非特權使用者命名空間的創建。
如果您正在尋找資源，關於命名空間的 LWN 系列的其餘部分會更深入地介紹該主題。