為什麼 Fedora 創建 /root 權限為 r-xr-x---？
是否有任何文件說明我
/root被所有者標記為不可寫的原因？(r-xr-x---)我知道，憑藉 CAP_DAC_OVERRIDE，它的所有者通常會擁有寫訪問權限。然而，看到這一點，我仍然感到驚訝。所以我很好奇是否有什麼我可以從中學到的！
Debian 的方法在我看來更自然。在 Debian 上，權限是
rwx------.$ rpm -q --whatprovides /root filesystem-3.2-37.fc24.x86_64 $ sudo dnf info filesystem | grep Release Release : 37.fc24 $ grep ^VERSION= /etc/os-release VERSION="25 (Workstation Edition)"
這在 2009 年左右在 Fedora 中發生了變化。來源：https ://bugzilla.redhat.com/show_bug.cgi?id=517575P
感謝@jordanm 指出這一點。我試圖複製相關的報價。免責聲明：我確信這個渲染在這個過程中失去了一些東西。
這些更改取消了 root 的寫入權限，因此您還需要 DAC_OVERRIDE 才能寫入。然後，我們放棄了需要 root 權限但面向網路或 setuid 的功能。
批判性反應
無論如何，這是一個善意的想法，但實際上，如果沒有大量的進一步工作，它將無法工作，因為具有 uid 0 但不是 CAP_DAC_OVERRIDE 的程序仍然完全能夠重寫例如 /usr/bin/bash 仍然具有 u+w , 或 /root/.bashrc 。這類事情的答案是 SELinux。對將目錄恢復為模式 755 的更新檔有任何異議嗎？
來自作者的回答：
有什麼問題
$$ your software $$有？如果它試圖寫入系統目錄，它應該有問題。
回复：
這沒什麼大不了的，有效恢復它的程式碼 rpm-ostree 很小，隨著時間的推移應該不難攜帶。
我只是想交叉連結錯誤，以便其他任何遇到此問題的人都可以看到我們在 rpm-ostree 中所做的更改。
第三方感嘆詞：這是關於類的任何工具都需要處理這個問題的工具。
https://github.com/projectatomic/rpm-ostree/pull/335
連結到引入此問題的 Fedora 錯誤，並更改了一些內容，因此它也用於“撰寫”案例，因為：
- 同樣，它不會增加安全性
- 在“撰寫”儲存庫上執行的工具在結帳時必須解決此問題，請參閱例如https://lists.freedesktop.org/archives/xdg-app/2016-June/000241.html