Windows user can overwrite NFSv4/Solaris ACL permissions of files on CIFS/SMB share (grant himself full access), how to prevent this

access-control-listpermissionssolariswindowszfs

I have SMB/CIFS file sharing set up on an OmniOS server with the Solaris kernel module which uses NFSv4 ACLs that should work correctly with Windows clients.

I want to create a shared directory with the following goals: a user (let's say alice) should be able to create and modify files, but not delete them. Also creation of subdirectories should be prevented. Read access should be permitted.

I've tried the following ACL, which basically works:

/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

But if alice views the Security tab of the newly added files in the Windows Explorer, she can grant herself full access rights and delete the file afterwards, even if she does not have Co rights.

How to explain this behavior? And how can I change it so that ACLs cannot be modified?

Edit: Output of ls seems to be normal:

# /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

Output of ls for the directory itself:

# /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

The filesystem of the share is ZFS. The most interesting non-default properties are as follows:

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 share permissions are set to allow everyone full access, so only the file permission should apply.

Update:

This thread is very similar to my problem, although the solution with reducing the ACLs in /pool/share/.zfs/shares/testshare to modify_set for everyone (or denying users specific delete permissions) does not seem to work in my case and I don't know why.

Best Answer

IMHO everything gets really confusing if you remove the trivial acls for user,group,everyone. Things to consider:

  • In cases of deny permissions or when an access permission for a file is missing, the privilege subsystem determines what access request is granted for the owner of the file or for superuser. This mechanism prevents owners of files from getting locked out of their files and enables superuser to modify files for recovery purposes.
  • POSIX-draft based ACLs use a single entry to define which permissions are allowed and which permissions are denied. The new ACL model has two types of ACEs that affect access checking: ALLOW and DENY
  • The owner of a file is granted the write_acl permission unconditionally, even if the permission is explicitly denied.
  • If you change the permissions of the file, a file's ACL is updated accordingly. In addition, if you remove a non-trivial ACL that granted a user access to a file or directory, that user could still have access to the file or directory because of the file or directory's permission bits that grant access to a group or to everyone

So my approach is to modify the trivial acls according to the needs (use deny mode) and than add non-trivial acls for all the special use cases. Keep this in mind as well:

  • After an allow permission has been granted, it cannot be denied by a subsequent ACL deny entry in the same ACL permission set.

If have no idea what OmniOS is, but these documents helped me understand NFS ACL. We use Solaris with ZFS https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

Related Topic