Unix

為什麼組上的 chmod(1) 會影響 ACL 遮罩?

  • March 1, 2012

我試圖了解這種 Unix 行為(我碰巧在 Ubuntu 11.10 上進行測試):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

請注意,chmod(1) 命令已更新 ACL 遮罩。為什麼會這樣?

SunOS 手冊頁有以下說明:

如果您使用 chmod(1) 命令更改具有 ACL 條目的文件的文件組所有者權限,則文件組所有者權限和 ACL 遮罩都將更改為新權限。請注意,新的 ACL 遮罩權限可能會更改對文件具有 ACL 條目的其他使用者和組的有效權限。

我問是因為如果 chmod(1) 沒有這種行為對我來說會很方便。我希望通過理解它為什麼這樣做,我可以更好地設計我如何設置文件系統權限。

如果沒有chmod()這種行為,對您來說將不方便。

這將非常不方便,因為人們傳統上期望在 Unix 上工作的東西會被破壞。這種行為對你很有幫助,你知道嗎。

遺憾的是 IEEE 1003.1e 從未成為標準並於 1998 年被撤銷。實際上,十四年過去了,從LinuxFreeBSD再到Solaris ,它是一個廣泛的作業系統實際實施的標準。

IEEE 1003.1e 工作草案 #17 讀起來很有趣,我推薦它。在附錄 B § 23.3 中,工作組提供了一個詳細的、八頁的基本原理,說明 POSIX ACL 相對於舊S_IRWXG組權限標誌的工作方式有些複雜。(值得注意的是,TRUSIX 人十年前提供了大致相同的分析。)我不打算在這裡全部複製。閱讀標準草案中的基本原理以了解詳細資訊。這是一個非常簡短的概要:

  • SunOS 手冊是錯誤的。它應該

如果您使用該chmod(1)命令更改具有 ACL 條目的文件的文件組所有者權限,文件組所有者權限ACL 遮罩將更改為新權限。

這是您可以看到的行為,儘管目前手冊頁在您的問題中說了什麼。這也是 POSIX 標準草案指定的行為。如果存在CLASS_OBJ(Sun 和 TRUSIX 的術語ACL_MASK)訪問控制條目,則 a 的組位chmod()設置它,否則它們設置GROUP_OBJ訪問控制條目。

  • 如果不是這種情況,使用 chmod() 執行各種標準操作的應用程序,期望它像 chmod() 傳統上在舊的非 ACL Unix 上工作,要麼留下巨大的安全漏洞,要麼看看什麼他們認為這是巨大的安全漏洞:

    • 傳統的 Unix 應用程序希望能夠拒絕對文件、命名管道、設備或目錄的所有訪問chmod(…,000)。在存在 ACL 的情況下,如果S_IRWXG映射到CLASS_OBJ. 如果沒有這個,將舊文件權限設置為000不會影響任何USERGROUP條目,令人驚訝的是,其他使用者仍然可以訪問該對象。

    暫時將文件的權限位更改為無訪問權限,chmod 000然後再將其更改回來是舊的文件鎖定機制,在 Unix 獲得建議鎖定機制之前使用,如您所見,人們今天仍在使用

    • 傳統的 Unix 腳本期望能夠執行chmod go-rwx並最終只有對象的所有者才能訪問該對象。再一次——正如你所看到的——這仍然是十二年後的公認智慧。同樣,除非舊S_IRWXG映射到CLASS_OBJ它是否存在,否則這不起作用,因為否則該chmod命令不會關閉任何USERGROUP訪問控制條目,導致所有者和非所有者組以外的使用者保留對某些東西的訪問權限預計**只有所有者可以訪問。
    • 權限位與 ACL 分開並and與 ACL 一起編輯的系統在大多數情況下都需要文件權限標誌rwxrwxrwx,這會混淆許多 Unix 應用程序,這些應用程序在看到他們認為是世界可寫的內容時會抱怨東西。

    權限位與 ACL 分開並 or與 ACL 一起編輯的系統會chmod(…,000)出現前面提到的問題。

進一步閱讀

引用自:https://serverfault.com/questions/352783