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

前端之家收集整理的这篇文章主要介绍了Windows用户可以覆盖CIFS / SMB共享上的文件的NFSv4 / Solaris ACL权限(授予自己完全访问权限),我该如何防止这种情况?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在具有Solaris内核模块的OmniOS服务器上设置了SMB / CIFS文件共享,该模块使用可与 Windows客户端正常工作的NFSv4 ACL.

我想创建一个具有以下目标的共享目录:用户(比如alice)应该能够创建和修改文件,但不能删除它们.还应该防止创建子目录.应允许读访问权限.

我尝试过以下ACL,它基本上可以工作:

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

但是,如果alice在Windows资源管理器中查看新添加文件的“安全”选项卡,则她可以授予自己完全访问权限并在之后删除文件,即使她没有Co权限也是如此.

如何解释这种行为?我怎样才能更改它以便无法修改ACL?

编辑:ls的输出似乎正常:

  1. # /usr/bin/ls -v
  2. total 1
  3. -rwx------+ 1 alice staff 3 2016-03-21 test.txt
  4. 0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
  5. /execute/delete_child/read_attributes/write_attributes/delete
  6. /read_acl/write_acl/write_owner/synchronize:inherited:allow
  7. 1:user:alice:read_data/write_data/append_data/read_xattr
  8. /write_xattr/execute/read_attributes/write_attributes/read_acl
  9. /synchronize:inherited:allow
  10.  
  11. # /usr/bin/ls -V
  12. total 1
  13. -rwx------+ 1 alice staff 3 2016-03-21 test.txt
  14. user:root:rwxpdDaARWcCos:------I:allow
  15. user:alice:rwxp--aARWc--s:------I:allow

输出目录本身的ls:

  1. # /usr/bin/ls -Vd
  2. drwx------+ 3 root root 4 2016-03-21 .
  3. user:root:rwxpdDaARWcCos:fd-----:allow
  4. user:alice:rwx---a-R-c--s:-------:allow
  5. user:alice:rwxp--aARWc--s:f-i----:allow
  6.  
  7. # /usr/bin/ls -vd
  8. drwx------+ 3 root root 4 2016-03-21 .
  9. 0:user:root:list_directory/read_data/add_file/write_data
  10. /add_subdirectory/append_data/read_xattr/write_xattr/execute
  11. /delete_child/read_attributes/write_attributes/delete/read_acl
  12. /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
  13. 1:user:alice:list_directory/read_data/add_file/write_data
  14. /read_xattr/execute/read_attributes/read_acl/synchronize:allow
  15. 2:user:alice:list_directory/read_data/add_file/write_data
  16. /add_subdirectory/append_data/read_xattr/write_xattr/execute
  17. /read_attributes/write_attributes/read_acl/synchronize
  18. :file_inherit/inherit_only:allow

共享的文件系统是ZFS.最有趣的非默认属性如下:

  1. NAME PROPERTY VALUE SOURCE
  2. pool/share type filesystem -
  3. pool/share compression lz4 inherited from pool
  4. pool/share atime off local
  5. pool/share aclmode restricted local
  6. pool/share aclinherit passthrough local
  7. pool/share version 5 -
  8. pool/share utf8only on -
  9. pool/share normalization formD -
  10. pool/share casesensitivity insensitive -
  11. pool/share nbmand on local
  12. pool/share sharesmb name=testshare local

CIFS共享权限设置为允许每个人完全访问权限,因此只应应用文件权限.

更新:

This thread与我的问题非常相似,虽然将/pool/share/.zfs/shares/testshare中的ACL减少到每个人的modify_set(或拒绝用户特定的删除权限)的解决方案在我的情况下似乎不起作用我不喜欢不知道为什么.

恕我直言,如果你删除用户,组,每个人的琐碎acls,一切都会让人感到困惑.需要考虑的事项:

>如果拒绝权限或缺少文件的访问权限,则权限子系统将确定为文件所有者或超级用户授予的访问权限请求.此机制可防止文件所有者被锁定在其文件之外,并使超级用户能够修改文件以进行恢复.
>基于POSIX草案的ACL使用单个条目来定义允许哪些权限以及拒绝哪些权限.新的ACL模型有两种类型的ACE影响访问检查:ALLOW和DENY
>即使明确拒绝了权限,也会无条件地授予文件所有者write_acl权限.
>如果更改文件的权限,则会相应地更新文件的ACL.此外,如果删除授予用户访问文件或目录的非平凡ACL,则该用户仍可以访问该文件或目录,因为文件或目录的权限位可授予对组或每个人的访问权限

所以我的方法是根据需要修改普通的acls(使用deny模式),然后为所有特殊用例添加非平凡的acls.记住这一点:

>授予允许权限后,相同ACL权限集中的后续ACL拒绝条目不能拒绝该权限.

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

猜你在找的Windows相关文章