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

Question

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.

Answer 1

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

Answer 2

After ignoring this problem for a week, it now suddenly works... I don't know what has caused it, but it works... I have tried the suggestion from this blog, but modified it to include AW as rights. Then I tested it again, this time only with my older deny rules (overwriting the new ones completely), that also worked. Finally I used the very first settings from my own question which never worked, but now they did.

After some more testing, I think it was because the SMB service was not restarted before and the share ACLs where not recognized correctly. Changing them was the only way I could restore the old (and wrong) behavior.

So, for future reference, the solution is to define the normal permissions on the files themselves, and not allow Co permissions on the share level:

1. Apply the following ACL rules to the directory and (inherited) to all newly created files:

   /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. Apply the following ACL rules to the ZFS dataset's hidden share directory (this is needed to prevent the owner from modifying ACLs, for details see @embedded's answer and the linked serverfault post):

   /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. Restart the SMB server (needed to update changed share ACLs, see this thread):

   svcadm restart svc:/network/smb/server:default # restart service
   svcs -xv svc:/network/smb/server:default       # check if the startup date has changed
   

Now new files can be created and written, but not deleted and also Windows users cannot give themselves additional rights. This solution works fine for my situation, but I can see two small downsides:

• You have to remember/document that you changed the share level, if additional permissions should be set in the future.
• It is possible that a user modifies the content of documents. For example, alice can overwrite chars or lines in a text document. I think this is because the application I use needs the append and write privileges and there is no ACL that checks for "initial write only" or similar.