4

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.

  • Post the output of ls -v /pool/share and/or ls -V /pool/share. – Andrew Henle Mar 21 '16 at 16:36
  • @AndrewHenle Thanks for the suggestion, I edited my question with the results of ls. – user121391 Mar 21 '16 at 17:05
  • Does the alice user actually own the directory? – Andrew Henle Mar 21 '16 at 18:18
  • No, root owns it. Although it shouldn't matter, should it? I have removed all owner/group/everyone permissions from it, so ownership should not matter much? – user121391 Mar 22 '16 at 8:42
  • If alice owns the directory, that user would definitely be able to delete files in it through normal Unix-style permissions. Could you post the output of ls -vd /pool/share? That should be the correct command to post the ACLs and permissions of the directory itself. And I assume the underlying file system is ZFS? – Andrew Henle Mar 22 '16 at 10:24
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

  • Thank you for your answer, I was not aware of this security fallback, I will test with additional users/non-owners. OmniOS is an illumos-based distribution, I think the ZFS and ACL behaviour should not differ much from Solaris 10. – user121391 Mar 23 '16 at 15:02
  • Could you please explain your approach a bit more? I tried to first deny deletion and acl change permissions and then allow user-based, but it is not different from before. Or is it still impossible to work around the owner-acl limitation you outlined earlier? – user121391 Mar 24 '16 at 10:00
  • I also updated my post with a link to a very similar problem, but that solution did not help in my case. – user121391 Mar 24 '16 at 10:07
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.