Windows

Windows 使用者可以覆蓋 CIFS/SMB 共享上文件的 NFSv4/Solaris ACL 權限（授予自己完全訪問權限），我該如何防止這種情況？

  • April 5, 2016

我在具有 Solaris 核心模組的 OmniOS 伺服器上設置了 SMB/CIFS 文件共享，該核心模組使用 NFSv4 ACL，應該可以與 Windows 客戶端正常工作。

我想創建一個具有以下目標的共享目錄：使用者（假設alice）應該能夠創建和修改文件，但不能刪除它們。還應防止創建子目錄。應該允許讀訪問。

我嘗試了以下 ACL，它基本上可以工作：

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

但是，如果在 Windows 資源管理器中查看新添加文件alice的安全選項卡，她可以授予自己完全訪問權限並在之後刪除該文件，即使她沒有Co權限。

如何解釋這種行為？以及如何更改它以使 ACL 不能被修改？

編輯： 的輸出ls似乎是正常的：

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
   0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
       /execute/delete_child/read_attributes/write_attributes/delete
       /read_acl/write_acl/write_owner/synchronize:inherited:allow
   1:user:alice:read_data/write_data/append_data/read_xattr
       /write_xattr/execute/read_attributes/write_attributes/read_acl
       /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
   user:root:rwxpdDaARWcCos:------I:allow
   user:alice:rwxp--aARWc--s:------I:allow

ls目錄本身的輸出：

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
   0:user:root:list_directory/read_data/add_file/write_data
       /add_subdirectory/append_data/read_xattr/write_xattr/execute
       /delete_child/read_attributes/write_attributes/delete/read_acl
       /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
   1:user:alice:list_directory/read_data/add_file/write_data
       /read_xattr/execute/read_attributes/read_acl/synchronize:allow
   2:user:alice:list_directory/read_data/add_file/write_data
       /add_subdirectory/append_data/read_xattr/write_xattr/execute
       /read_attributes/write_attributes/read_acl/synchronize
       :file_inherit/inherit_only:allow

共享的文件系統是 ZFS。最有趣的非預設屬性如下：

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

CIFS 共享權限設置為允許所有人完全訪問，因此應僅應用文件權限。

更新：

該執行緒與我的問題非常相似，儘管在我的情況下減少 ACL 的解決方案/pool/share/.zfs/shares/testshare（modify_set或拒絕使用者特定的刪除權限）似乎不起作用，我不知道為什麼。

在忽略了這個問題一周後，它現在突然起作用了……我不知道是什麼原因造成的，但是它起作用了……我嘗試了此部落格的建議，但將其修改為包含AW為權利。然後我再次對其進行了測試，這次只使用了舊的拒絕規則（完全覆蓋新規則），這也有效。最後，我使用了我自己的問題中的第一個設置，這些設置從未奏效，但現在他們做到了。

經過更多測試，我認為這是因為之前未重新啟動 SMB 服務，並且無法正確辨識共享 ACL。改變它們是我可以恢復舊的（和錯誤的）行為的唯一方法。

因此，為了將來參考，解決方案是定義文件本身的正常權限，而不是Co共享級別的權限：

  1. 將以下 ACL 規則應用於目錄和（繼承）所有新創建的文件：
/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share
  1. 將以下 ACL 規則應用於 ZFS 數據集的隱藏共享目錄（這是防止所有者修改 ACL 所必需的，有關詳細資訊，請參閱@embedded 的答案和連結的 serverfault 文章）：
/usr/bin/chmod A=\
user:root:full_set:-------:allow,\          # root has full access
everyone@:modify_set:-------:allow \        # anyone else cannot modify permissions
/pool/share/.zfs/shares/testshare
  1. 重新啟動 SMB 伺服器（需要更新更改的共享 ACL，請參閱此執行緒）：
svcadm restart svc:/network/smb/server:default # restart service
svcs -xv svc:/network/smb/server:default       # check if the startup date has changed

現在可以創建和寫入新文件，但不能刪除，Windows 使用者也不能賦予自己額外的權限。該解決方案適用於我的情況，但我可以看到兩個小缺點：

  • 如果將來應該設置其他權限，您必須記住/記錄您更改了共享級別。
  • 使用者可能會修改文件的內容。例如，alice可以覆蓋文本文件中的字元或行。我認為這是因為我使用的應用程序需要附加和寫入權限，並且沒有 ACL 檢查“僅初始寫入”或類似內容。

恕我直言，如果您刪除使用者、組和每個人的瑣碎 acl，一切都會變得非常混亂。需要考慮的事項：

  • 在拒絕權限或缺少文件訪問權限的情況下，權限子系統確定授予文件所有者或超級使用者的訪問請求。這種機制可以防止文件所有者被鎖定在他們的文件之外，並使超級使用者能夠修改文件以進行恢復。
  • 基於 POSIX 草案的 ACL 使用單個條目來定義允許哪些權限以及拒絕哪些權限。新的 ACL 模型有兩種影響訪問檢查的 ACE：ALLOW 和 DENY
  • 文件的所有者無條件地被授予 write_acl 權限，即使該權限被明確拒絕。
  • 如果您更改文件的權限，文件的 ACL 也會相應更新。此外，如果您刪除授予使用者訪問文件或目錄的非普通 ACL，則該使用者仍然可以訪問文件或目錄，因為文件或目錄的權限位授予組或所有人訪問權限

所以我的方法是根據需要修改瑣碎的 acls（使用拒絕模式），而不是為所有特殊案例添加非瑣碎的 acls。請記住這一點：

  • 授予允許權限後，不能被同一 ACL 權限集中的後續 ACL 拒絕條目拒絕。

如果不知道 OmniOS 是什麼，但這些文件幫助我了解 NFS ACL。我們使用帶有 ZFS 的 Solaris https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

引用自：https://serverfault.com/questions/765104

相關問答

Windows

Windows - 僅在文件夾上設置權限而不遞歸子對象（大型目錄樹慢）

  • April 30, 2019
檢視問答
Solaris

如何將 ZFS ACL 從一個文件複製到另一個文件？

  • March 22, 2017
檢視問答
Windows

從 Windows 客戶端通過 ZFS SMB 對在 OpenIndiana 的主機上創建的文件進行寫入訪問

  • December 7, 2012
檢視問答
Windows

ZFS CIFS 共享，客戶端看不到根文件夾中其他共享的掛載點？

  • March 2, 2012
檢視問答
Windows

將 Windows 權限委派給不同的管理員組

  • October 19, 2011
檢視問答
Windows

找不到使用者帳戶來設置私鑰的權限

  • April 1, 2022
檢視問答