ACL 如何計算文件的有效權限?
我執行以下命令為
wheel
組rwx
授予對創建的新文件和子目錄的權限:[belmin@server1]$ ls -la total 24 drwxr-sr-x+ 2 guards guards 4096 Aug 27 15:30 . drwxr-xr-x 104 root root 12288 Aug 27 15:19 .. [belmin@server1]$ sudo setfacl -m d:g:wheel:rwX . [belmin@server1]$ getfacl . # file: . # owner: guards # group: guards # flags: -s- user::rwx group::r-x group:wheel:rwx other::r-x default:user::rwx default:group::r-x default:group:wheel:rwx default:mask::rwx default:other::r-x
但是,當我以 root 身份創建文件時,我並不完全清楚
effective
權限是如何計算的:[belmin@server1]$ sudo touch foo [belmin@server1]$ getfacl foo # file: foo # owner: root # group: guards user::rw- group::r-x #effective:r-- group:wheel:rwx #effective:rw- group:guards:rwx #effective:rw- mask::rw- other::r--
有人可以詳細說明這意味著什麼嗎?
effective
權限是通過將實際(真實?)權限與mask
. 由於mask
您的文件是rw-
,因此所有effective
權限都已x
關閉。
簡短回答:如果您想要使用執行位的遮罩,則必須使用
setfacl
after顯式設置它touch
。安全性禁止其隱式設置。setfacl -n -m m::rwx foo
“-n”禁止重新計算遮罩(可能不需要)。
“m::rwx” 將遮罩值設置為 ‘rwx’。請注意,“m::x”將禁用所有讀取和寫入。
我無法說明為什麼面具是“rw-”。我假設
touch
創建文件的預設目錄對於整個 OP 範例保持不變。
- ‘foo’ 的目錄條目應該顯示所有者 ‘root’(因為 sudo 命令和組 ‘guards’ 因為該目錄設置了 SUID 位。權限將是預設值 ‘-rw-…r–‘目錄 ‘-…rx…’ 的組權限(由於 SUID 位顯示為小 s)。
- 接下來是 ACL,它應該是目錄預設值。鑑於 ACL 繼承,我不希望創建任何 ACLe,並且 ACLE 遮罩是目錄預設值“rwx”。
但如果它們被創建,我希望新的 ACLe 會從預設值開始,再次將遮罩保留在“rwx”。如果它們沒有從預設值啟動,這似乎違背了預設 ACL 的想法——“預設”ACL 將僅提供命名使用者和命名組 ACL。
這就引出了一個問題,即面具 ACLe 應該是什麼。我希望它是預設遮罩條目中的“rwx”。但它可以用空白遮罩創建,然後適用各種法律術語。
- 使用 user::rw-、group::rx、other::r–、group:wheel:rwx、group:guards:rwx 和 mask:::(未設置)的暫定 ACL,我們查閱文件
setfacl
,假設相同的規則適用於文件創建。有一個子句:
如果 ACL 包含命名使用者或命名組條目,並且不存在遮罩條目,則創建與組條目具有相同權限的遮罩條目。
如果 ACL 組條目是從文件目錄條目創建的,則這會將 ACL 遮罩設置為“rx”,如果 ACL 組條目來自預設 ACL,則將其設置為“rx”。(以另一種方式,對於這種情況,結果是相同的。)
還有一個條款:
如果預設 ACL 包含命名使用者條目或命名組條目,並且不存在遮罩條目,則添加與預設預設 ACL 的組條目具有相同權限的遮罩條目。…遮罩條目的權限進一步調整為包括受遮罩條目影響的所有權限的並集。
如果此規則適用,則遮罩將以“rx”(與上一條相同的邏輯)開頭),然後將其調整為“受遮罩條目影響的所有權限的並集”。
setfacl
命令文件中未定義“受遮罩條目影響的權限” 。POSIX ACL 文件說:遮罩是所屬組的所有訪問權限以及所有使用者和組條目的組合。
給出“聯合”這個詞,它是加法的,我會將“組合”讀作邏輯或。換句話說,如果任何組或使用者 ACLe 具有“x”權限,則遮罩將包含“x”。
- 通過所有這些邏輯,OP 範例中的遮罩值應該是“rwx”,無論遵循哪個邏輯路徑。
上面的推理一定是有缺陷的,因為執行的 x 沒有出現在遮罩中。
因此,必須有一些關於如何計算遮罩的規則,這些規則已經從常見的文件源中“隱藏”(或者我們發現了一個錯誤)。
我的結論是“x”總是被無條件地刪除,並且文件鬆懈。
此更改可能是基於“安全性”的正當理由進行的 - 任何文件都不應是隱式可執行的,但必須在創建後打開可執行位。