按路徑而不是文件模式位的權限

我經常發現處理文件權限的 unix 方式很強大，尤其是與 ACL 結合使用時，但處理起來相當困難。為每個創建的文件正確設置文件模式、組所有權和擴展屬性很快就會變得乏味。

是否有任何方法可以用更簡單的方法替換這個概念（可能是每次安裝），預設情況下文件從其包含目錄繼承權限？

我知道這可能會違反一些 POSIX 的期望，但另一方面，像安靜的 vfat mouts 這樣的東西已經無視模式和一些權限更改，因此不應阻止開發新的想法。

舉個例子，我正在尋找一些東西，我可以確定只要使用者將他的文件放在某個目錄中，它就可以被給定的組寫入和刪除，並且只能被世界其他地方讀取, 無論使用者的 umask 和目前組。

到目前為止我所知道的似乎還不夠的原因：

• **限制目錄中的許可文件：**將 umask 更改為 0777 並將目錄模式更改為 0770，可以授予組內的讀寫訪問權限並鎖定世界其他地方。dir 還必須設置 sgid 位，以便其文件獲得正確的組而不是使用者的主要組。但是 0777 的 umask 有在不受這種方式限制的地方打開大洞的風險，如果人們開始使用 mv 移動東西，umask 就沒有多大意義了。
• **ACL 預設值：**使用 setfacl 可以為給定目錄中新創建的文件設置預設值。這比上面的要好，但它只適用於新創建的文件。如果人們開始四處移動文件，這將不起作用，並且對於 umask 過於嚴格的情況同樣不起作用。

有沒有什麼方法可以用更簡單的方法替換這個概念（可能是每次安裝），預設情況下文件從其包含的目錄繼承權限？

是的，它們被稱為預設 ACL：

[root@ditirlns02 acl-test]# setfacl -m d:u:jadavis6:rwx --mask .
[root@ditirlns02 acl-test]# getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

[root@ditirlns02 acl-test]# mkdir subDir
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# getfacl subDir/testFile
# file: subDir/testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# mkdir subDir/nestedDir
[root@ditirlns02 acl-test]# getfacl subDir/nestedDir
# file: subDir/nestedDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

有點繁瑣的例子，但它說明了預設 ACL 在創建時繼承到子目錄，並直接（作為有效的 ACE）應用於目錄和文件。按照設計，預設 ACL 的更改不會主動下降。Unix 力求盡可能保持惰性，因此期望如果您希望將新權限應用於已經存在的文件，那麼您將做一些setfacl或chmod魔術來完成它。自動更改甚至是不可取的。您會經常聽到意外打開的文件，或者管理員沒有考慮嵌套在已更改目錄下的特定目錄，該目錄用於現在被鎖定的應用程序等。

但是 0777 的 umask 有在不受這種方式限制的地方打開大洞的風險

好吧，這實際上與您的第一點無關，但是 POSIX ACL 也可以解決此問題。在允許性方面，ACL 遮罩勝過使用者 shell 中的 umask 設置（實際上它們可以一起工作，因為 ACL 遮罩會拒絕權限，而 umask 不會授予權限，從而導致隱式拒絕）。您可以使用以下setfacl命令對其進行修改：

[root@ditirlns02 acl-test]# setfacl -m m:r-x testFile
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:r-x
group::r-x
mask::r-x
other::r--

如您所見，即使我個人帳戶上的基本 DAC 讓我處於“rwx”，我的帳戶仍然只能獲得“rx”，因為 ACL 遮罩阻止了這種情況的發生。您還可以像管理其他預設 ACL 條目一樣管理預設 ACL 遮罩：

[root@ditirlns02 acl-test]# getfacl afterMask
# file: afterMask
# owner: root
# group: root
user::rwx
user:jadavis6:rwx               #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx       #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

我回到了之前的目錄，所以你可以看到“沒有自動重新計算”在起作用。

Again this won't work if people start moving files around

我有點超前了，所以我已經解決了為什麼這是不可取的行為，但我可以詳細說明。基本上，確實，如果您更改預設 ACL，您幾乎總是希望更改已經存在的 ACL。問題在於您無法設計一個系統來正確預測權限應該是什麼。如果你這樣做了，你就會對其他安全和穩定性問題敞開心扉。

例如：

• 您有一個文件夾，/srv/applicationX/shares/accounting/deftManeuver其中包含有關您公司在各個市場中的表現的專有資訊，只有某些人才能訪問它。
• /srv/applicationX/shares 通過 samba 或 NFS 共享，並在公司範圍內使用。
• 一個新部門成立，不同的組成員要求您在共享目錄上給他們 rwx。
• 新部門現在可以訪問專有資訊。更糟糕的是，您甚至沒有意識到權限是這樣設置的，因為您已經一年沒有做任何事情了，deftManeuver所以您甚至忘記了它在那裡。

這是一個極端的例子，但它說明了問題。讓權限保持惰性，該平台至少可以說“這些權限過去是可以接受的，所以也許它們仍然非常接近他們想要做的事情。” 而在 Windows 世界中，您有權更改您甚至不知道存在的文件的訪問控制。

這樣，您可以設置deftManeuver一次具有適當的限制，如果您需要打開它，那麼平台強迫您明確告訴它“我想要目錄 abc 及其後代上的 xyz”，平台至少可以對沖它賭你不做遞歸 setfacl。

在我的工作生活中，我曾多次被此功能所拯救。我打開一個目錄太多來解決問題，安全人員告訴我“嘿嘿嘿，不，不要那樣做”，在過渡期間，只有新文件對它們有不安全的權限而不是幾年/幾十年積累的資訊。

編輯（可選的 ACL 咆哮）：

這並不是說 POSIX ACL 沒有實際問題，只是這裡列出的反對意見要麼在模型中處理，要麼是功能而不是缺陷。

正常 POSIX ACL 的問題在於表現力。您仍然只能獲得 rwx，但應該針對更多操作。Windows/NTFS 對權限採取了一種霰彈槍的方法，包括一些沒有意義的東西（比如沒有遮罩的原生概念，每個使用者的刪除權限，而不是 Unix 的方式說“如果它是一個文件名，那麼保留一個文件名是沒有意義的空文件，因此將其折疊為“寫入”或附加權限等），但包含許多確實很有意義的事情，例如擁有附加權、更改權限的權利、獲得所有權的權利等。

還有一些小事情，例如無法為每個使用者或（更好）每個組設置遮罩：

[root@ditirlns02 acl-test]# setfacl -m m:g:testGroup:rwx .
setfacl: Option -m: Invalid argument near character 3
[root@ditirlns02 acl-test]#

所以沒有辦法明確地允許某些有效權限超過遮罩（一般規則的好處並不總是如此，這迫使人們在不同使用者之間長時間的工作之間做出決定，或者設置一個過於寬鬆的遮罩。猜猜哪條路線通常採取…）

老實說，我認為沒有人以如此全面、富有表現力和安全的方式來授予權限。

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