使用 ZFS ACL 在 OmniOS (Illumos) 上繼承組寫入權限，但不執行文件
我們
umask 027大部分時間都在運作。對於涉及多個使用者的某些目錄，我發現了一種umask 002使用 ACL 繼承來模擬的很酷的方法。這是我正在使用的命令。本質上這是
chmod 775與繼承：/usr/bin/chmod A=owner@:rwxpDaARWcCos:fd:allow,group@:rwxpDaARWcs:fd:allow,everyone@:rxaRcs:fd:allow $@`
$@表示要更新的文件列表。我在 中使用 OpenSolaris 版本/usr/bin/chmod，因為/usr/gnu/bin/chmod它似乎不支持完整的 ACL 語法。像魅力一樣工作，並且還設置
g+s為繼承組名。但是，我需要一些改進：
- （
a+x執行）權限應僅適用於目錄，不應自動為文件繼承。- （
o+r讀取）權限應該只適用於文件，而不是目錄，因為我想禁用ls匿名使用者的能力。我對 OmniOS/Illumos 和 ZFS 非常滿意，但不幸的是，它使用 Solaris ACL 方案，這與更常見的 Linux ACL 語法完全不同。
某種條件繼承是有序的，一種方式繼承文件，另一種方式繼承目錄。這可能嗎？
a+x（執行）權限應該只適用於目錄，而不應該被自動繼承給文件。
您可以為 ACL（完整列表）的每個 ACE（訪問控制條目）指定應如何繼承。這些選項取自Solaris 管理指南，它也適用於 OmniOS（表 8.1 到 8.3）：
- *file_inherit(f)：*只繼承父目錄的ACL到目錄的文件。
- *dir_inherit(d)：*只繼承父目錄的ACL到目錄的子目錄。
- *inherit_only (i)：*從父目錄繼承 ACL，但僅適用於新創建的文件或子目錄，而不適用於目錄本身。需要 f/d/fd。
- *no_propagate(n)：*只繼承父目錄的ACL到目錄的一級內容，不繼承二級或後續內容。需要 f/d/fd。
您可以為同一個使用者添加多個 ACE 並達到預期的效果，因為它們在應用時是組合在一起的（類似於 Windows ACL）。範例簡化為@owner，因為對於其他人來說它是相同的：
/usr/bin/chmod A=\ owner@:rw-p-D-ARWcCos:fd-----:allow, \ owner@:--x---a-------:-d-----:allow, \ [...] $@這意味著
- 第一個 ACE 應用於目錄，並為所有文件和目錄繼承，但不包括 a+x 權限
- 第二個ACE應用於目錄並為所有子目錄繼承，但不適用於文件，只有a+x權限
- 要獲得生成的完整 ACL，您可以“覆蓋”目錄的兩行（這就是為什麼我更喜歡帶有破折號的語法，您會看到缺少的內容）
我沒有測試過它是否可以滿足您的要求，它有時也取決於應用程序，因此您應該對其進行測試。
I繼承的文件和目錄 ACL在最後一個位置用大號標記，例如owner@:rw-p-D-ARWcCos:fd----I:allow.o+r （讀取）權限應該只適用於文件，而不是目錄，因為我想禁用匿名使用者的 ls 功能。
與第一個問題類似，但反過來。
n如果您只想要一級繼承（類似於） ，也可以將其與find -maxdepth 1。再次注意測試，因為很可能簡單的標誌還不夠，您還需要高級標誌 (ARWC)。此外，您仍然可以使用文件和目錄選項遞歸地應用 ACLchmod -R，這在某些情況下可能需要（例如，如果 ACL 應該被追溯修改，因為一旦寫入文件，它的 ACL 就固定了，具體取決於 的屬性aclinherit） .我對 OmniOS/Illumos 和 ZFS 非常滿意，但不幸的是，它使用 Solaris ACL 方案，這與更常見的 Linux ACL 語法完全不同。
現在從您的角度來看，這可能看起來很不幸，但是 ACL 與 NFSv4 ACL 緊密建模，因此如果您決定使用 NFS 版本 4，則無需更改任何內容。它也緊密代表 Windows ACL（唯一的例外：SOLaris 上的順序是已修復，Windows 上的順序總是在允許之前拒絕，但如果您不使用拒絕也沒關係），這意味著您可以從每台
Co權限設置為允許的 Windows PC 中編輯權限。這適用於域和工作組，因此與 Windows 的互操作性優於 Samba 過去採用的解決方法。