主页 / server / 问题 / 765104
Accepted
user121391
Asked: 2016-03-22 06:23:39 +0800 CST

Windows 用户可以覆盖 CIFS/SMB 共享上文件的 NFSv4/Solaris ACL 权限（授予自己完全访问权限），我该如何防止这种情况？

  • 772

我在具有 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或拒绝用户特定的删除权限）似乎不起作用，我不知道为什么。

windows

2 个回答

  1. 恕我直言，如果您删除用户、组和每个人的琐碎 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

    • 1
  2. Best Answer

    在忽略了这个问题一周后，它现在突然起作用了……我不知道是什么原因造成的，但是它起作用了……我尝试了此博客的建议，但将其修改为包含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

    2. 将以下 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

    3. 重新启动 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 检查“仅初始写入”或类似内容。
    • 1

相关问题