Windows用户可以覆盖CIFS / SMB共享上文件的NFSv4 / Solaris ACL权限(授予他自己完全访问权限),那么如何防止此问题?

我在使用NFSv4 ACL的Solaris内核模块的OmniOS服务器上设置了SMB / CIFS文件共享,这些ACL应与Windows客户端正常工作。

我想创build一个共享的目录,其目标如下:一个用户(比方说alice )应该能够创build和修改文件,但不能删除它们。 还应该防止创build子目录。 应该允许读访问。

我已经尝试了以下ACL,基本上工作:

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

但是,如果alice在Windows资源pipe理器中查看新增文件的“ 安全”选项卡,她可以授予自己完整的访问权限,然后删除该文件,即使她没有共享权限。

如何解释这种行为? 我怎样才能改变它,使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---aRc--s:-------:allow user:alice:rwxp--aARWc--s:fi----: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共享权限设置为允许所有人完全访问,所以只有文件权限应该适用。

更新:

这个线程与我的问题非常相似,尽pipe针对每个人减less/pool/share/.zfs/shares/testsharemodify_set的ACL(或者拒绝用户特定的删除权限)的解决scheme似乎不适用于我的情况,而我不知道为什么。

恕我直言,一切都变得非常混乱,如果你删除用户,组,每个人的微不足道的acls。 需要考虑的事项:

  • 在拒绝权限或缺less文件访问权限的情况下,特权子系统确定为文件所有者或超级用户授予什么访问请求。 这种机制可以防止文件的所有者被locking在文件之外,并且允许超级用户修改文件以进行恢复。
  • 基于POSIX-draft的ACL使用单个条目来定义允许哪些权限以及哪些权限被拒绝。 新的ACL模型有两种影响访问检查的ACE:ALLOW和DENY
  • 即使权限被明确拒绝,文件的所有者也会无条件地被授予write_acl权限。
  • 如果更改文件的权限,则会相应地更新文件的ACL。 另外,如果删除允许用户访问文件或目录的非平凡ACL,则该用户仍然可以访问该文件或目录,因为该文件或目录的权限位授予对组或所有人的访问权限

所以我的方法是根据需要(使用拒绝模式)修改简单的acls,而不是为所有的特殊用例添加不重要的acls。 请记住这一点:

  • 授予允许权限后,不能被同一ACL权限集中的后续ACL拒绝表项拒绝。

如果不知道OmniOS是什么,但这些文件帮助我了解NFS ACL。 我们使用Solaris和ZFS https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

忽略这个问题一个星期后,现在突然发生作用…我不知道是什么造成的,但它的工作原理…我已经尝试了这个博客的build议,但修改它包括AW作为权利。 然后,我再次testing了一遍,这次只用我旧的拒绝规则(完全覆盖新的规则),这也是有效的。 最后,我使用了我自己的问题的第一个设置,从来没有工作,但现在他们做了。

经过一些更多的testing,我认为这是因为SMB服务没有重新启动之前,共享ACL不能正确识别。 改变他们是我能够恢复旧的(错误的)行为的唯一途径。

因此,为了将来的参考,解决scheme是定义文件本身的正常权限,并且不允许共享级别的共享权限:

  1. 将以下ACL规则应用于该目录,并将(inheritance)应用于所有新创build的文件:

     /usr/bin/chmod A=\ user:root:rwxpdDaARWcCos:fd-----:allow,\ # root has full access user:alice:rwx---aRc--s:-------:allow,\ # dir: create files, read everything user:alice:rwxp--aARWc--s:fi----:allow \ # files: wpAW is needed for full file write access, everything is only inherited to files /pool/share 
  2. 将以下ACL规则应用于ZFS数据集的隐藏共享目录(这是防止所有者修改ACL所必需的,有关详细信息,请参阅@ embedded的答案和链接的serverfaultpost):

     /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 

现在可以创build和写入新文件,但不能删除,Windows用户也不能赋予自己额外的权限。 这个解决scheme适用于我的情况,但我可以看到两个小缺点:

  • 您必须记住/logging您更改了共享级别,如果将来要设置其他权限。
  • 用户可能会修改文档的内容。 例如, alice可以覆盖文本文件中的字符或行。 我认为这是因为我使用的应用程序需要追加和写权限,并没有检查“初始只写”或类似的ACL。