Go to main content

Securing Files and Verifying File Integrity in Oracle® Solaris 11.4

Exit Print View

Updated: August 2018
 
 

Setting ACLs on ZFS Files

    The primary rules of ACL access on a ZFS file are as follows:

  • ZFS processes ACL entries in the order they are listed in the ACL, from the top down.

  • Only ACL entries where the specified user matches the requester of the access are processed.

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

  • The owner of the file is granted the write_acl permission unconditionally even if the permission is explicitly denied. Otherwise, any permission left unspecified is denied.

    In the cases of deny permissions or when an access permission is missing, the privilege subsystem determines the access request that 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.

Command Syntax for Setting ACLs

    To set or modify ACLs, use the chmod command. The command syntax resembles the syntax for setting permission bits on files, except that you specify A before typing the operator (+, =, or -).

  • Command syntax for trivial ACLs

    chmod [options] A[index]{+|=}owner@ |group@ |everyone@: \
      access-permissions/...[:inheritance-flags]:deny | allow \
    [:successful_access | failed_access:audit] file
    chmod [options] A-owner@, group@, everyone@: \
      access-permissions/...[:inheritance-flags]:deny | allow \
    [:successful_access | failed_access:audit] file 
    chmod [options] A[index]- file
  • Command syntax for non-trivial ACLs

    chmod [options] A[index]{+|=}user|group:name: \
    access-permissions/...[:inheritance-flags]:deny | allow \
    [:successful_access | failed_access:audit] file
    chmod [options] A-user|group:name: \
    access-permissions/...[:inheritance-flags]:deny | allow \
    [:successful_access | failed_access:audit] file ...
    chmod [options] A[index]- file

    The chmod command uses the following operators:

  • A+ adds an ACL entry.

  • A= replaces an ACL entry.

    To replace an entire ACL for a file, use this operator without specifying an index ID. In the following example, ACL entries for file.1 are removed and replaced with the single entry for everyone@.

    $ chmod A=everyone@:read_data:allow file.1
  • A- removes an ACL entry.

    To universally remove all non-trivial ACL entries for a file, use this operator and specify the file name without listing each entry to be removed.

    $ chmod A- filename

    Use this command syntax to restore a trivial ACL to the file. After you issue the command, only the entries for owner@, group@, and everyone@ that comprise a trivial ACL remain.


Caution

Caution  -  Be careful with modifying existing ACLs. Using the operators without an index has a different effect from using them with an index. For example, chmod A= replaces an entire ACL, while chmod A3= replaces only the existing entry that has index number 3.


Permissions and inheritance flags are represented by unique letters listed in Figure 8, Table 8, ACL Access Privileges and Figure 10, Table 10, ACL Inheritance Flags. When you set ZFS ACLs, you can either use the letters that correspond to those permissions (compact mode) or type the permissions in full (verbose mode).

    In this example, both commands grant read and execute permissions to user Alice on file.1:

  • chmod A+user:alice:rx:allow file.1

  • chmod A+user:alice:read_data/execute:allow file.1

    Likewise, to grant user Tamiko inheritable read, write, and execute permissions for the newly created dir.2 and its files, you can use either one of the following commands:

  • chmod A+user:tamiko:rwx:fd:allow dir.2

  • chmod A+user:tamiko:read_data/write_data/execute:file_inherit/dir_inherit:allow dir.2

Displaying ACL Information

With the ls command, you can display ACL information in one of two formats. The –v option displays the permissions in full or verbose form. The –V option generates compact output by using letters that represent the permissions and flags.

The following example shows how the same ACL information is displayed in both verbose and compact format:

$ ls -v file.1
-rw-r--r--   1 root     root      206695 Jul 20 14:27 file.1
0:owner@:read_data/write_data/append_data/read_attributes
/write_xattr/read_xattr/write_attributes/read_acl/write_acl
/write_owner/synchronize:allow
1:group@:read_data/read_attributes/read_xattr/read_acl
/synchronize:allow
2:everyone@:read_data/append_data/read_xattr/read_acl
/synchronize:allow

$ ls -V file.1
-rw-r--r--   1 root     root      206695 Jul 20 14:27 file.1
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow

For an explanation of the permissions for each user category, see Figure 8, Table 8, ACL Access Privileges.

Modifying ACLs on ZFS Files

This section provides sample commands for setting and displaying ACLs.

In the following example, write_data permissions are granted for group@. The index of group@ is 1.

# chmod A1=group@:read_data/write_data:allow file.1
$ ls -v file.1
-rw-rw-r--   1 root     root      206695 Jul 20 13:43 file.1
0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
1:group@:read_data/write_data:allow
2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
:allow

In the following example, read_data/execute permissions are added for the user Alice on the test.dir directory.

$ chmod A0+user:alice:read_data/execute:allow test.dir
$ ls -dv test.dir
drwxr-xr-x+  2 root     root           2 Jul 20 14:23 test.dir
0:user:alice:list_directory/read_data/execute:allow
1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/read_xattr/write_xattr/execute/delete_child
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
2:group@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow
3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow

In the following example, access permissions are removed for user Alice.

$ chmod A0- test.dir
$ ls -dv test.dir
drwxr-xr-x   2 root     root           2 Jul 20 14:23 test.dir
0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/read_xattr/write_xattr/execute/delete_child
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
1:group@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow
2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow

In the following example, auditing is set for everyone@ in dir.1. If any user attempts to access dir.1 and fails, that access failure is recorded in the audit log.

$ chmod A3=everyone@:list_directory/read_data/read_xattr/execute/read_attributes \
/read_acl/synchronize:allow:failed_access:audit dir1

$ ls -v
total 1
drwxr-xr-x 2 foo staff 2 Feb 1 19:28 dir1
     0:everyone@:list_directory/read_data/read_attributes/read_acl
         :failed_access:audit
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     2:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

ACL Interaction With Permission Bits

In ZFS files, the UNIX permission bits correspond to the ACL entries, but are cached. When you change a file's permission bits, the file's ACL is updated accordingly. Likewise, modifying a file's ACL causes changes in the permission bits.

For more information about permission bits, see chmod(1).

The following examples show the relationship between a file or directory's ACLs and the permission bits and how permission changes in one affect the other.

Example 8  ACLs and Permission Bits

The first example begins with the following ACL for file.2, whose permission bits are set to 644.

$ ls -v file.2
-rw-r--r--   1 root     root        2693 Jul 20 14:26 file.2Permission bits are 644.
0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
:allow

The chmod command removes the ACL entry for everyone@. Accordingly, the read permission bits for everyone are also removed and are changed to 640.

$ chmod A2- file.2Access is removed for everyone@
$ ls -v file.2
-rw-r-----   1 root     root        2693 Jul 20 14:26 file.2Permission bits become 640.
0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow

Next, the ACL is replaced with just read_data/write_data permissions for everyone@. No owner@ or group@ ACL entry exists to override the permissions for owner and group. Consequently, the permission bits become 666.

$ chmod A=everyone@:rw:allow file.2
$ ls -v file.2
-rw-rw-rw-   1 root     root        2440 Jul 20 14:28 file.3Permission bits become 666.
0:everyone@:read_data/write_data:allow

Next, the ACL is replaced with read permissions just for user Alice. The command, however, leaves no trivial ACL entries. Consequently, the permission bits are set to 000, which denies Alice access to file.2. The file effectively becomes inaccessible.

$ chmod A=user:alice:r:allow file.2
$ ls -v file.2
----------+  1 root     root        2440 Jul 20 14:28 file.3Permission bits become 000.
0:user:alice:read_data:allow

The example ends with showing how setting permission bits also update the ACL. The bits for file.2 are set to 655. Automatically, default trivial ACL permissions are set.

$ chmod 655 file.2
$ ls -v file.3
-rw-r-xr-x   1 root     root        2440 Jul 20 14:28 file.3Permission bits set to 655.
0:user:alice:read_data:allow
1:owner@:execute:denyBased on 655 bits, ACL execute permission is denied.
2:owner@:read_data/write_data/append_data/read_xattr/write_xattrDefault ACL entries restored.
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
3:group@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
4:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
Example 9  ACL Properties and Modified ACL Permissions

The following examples illustrate how specific aclmode and aclinherit property values affect ACL behavior. If these properties are set, ACL permissions for a file or directory are either reduced or expanded to be consistent with the owning group.

In this example, the administrator who runs the zfs set commands must be assigned the ZFS File System Management rights profile. To run the chown command, the administrator is assigned the Object Access Management rights profile.

Suppose that the aclmode property is set to mask and the aclinherit property is set to restricted in the pool, and that the original file and group ownership and ACL permissions are as follows:

$ pfbash ; zfs set aclmode=mask system1/data
$ zfs set aclinherit=restricted system1/data

$ ls -lV file.1
-rwxrwx---+  1 root     root      206695 Aug 30 16:03 file.1
user:amy:r-----a-R-c---:-------:allow
user:rory:r-----a-R-c---:-------:allow
group:sysadmin:rw-p--aARWc---:-------:allow
group:staff:rw-p--aARWc---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--aARWc--s:-------:allow
everyone@:------a-R-c--s:-------:allow

To understand the meaning of the values set for the two properties, see ACL Properties.

A chown operation changes file.1's ownership to Amy and the group Staff.

$ chown amy:staff file.1

Amy then changes file.1's permission bits to 640. Because of the ACL properties that were previously set, the permissions for the groups in the ACL are reduced in order to not exceed the permissions of the owning Staff.

$ su - amy
$ chmod 640 file.1
$ ls -lV file.1
-rw-r-----+  1 amy      staff     206695 Aug 30 16:03 file.1
user:amy:r-----a-R-c---:-------:allow
user:rory:r-----a-R-c---:-------:allow
group:sysadmin:r-----a-R-c---:-------:allow
group:staff:r-----a-R-c---:-------:allow
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow

Amy then changes the permission bits to 770. Consequently, the permissions of the groups in the ACL are also changed to match the permission of the owning group Staff.

$ chmod 770 file.1
$ ls -lV file.1
-rwxrwx---+  1 amy      staff     206695 Aug 30 16:03 file.1
user:amy:r-----a-R-c---:-------:allow
user:rory:r-----a-R-c---:-------:allow
group:sysadmin:rw-p--aARWc---:-------:allow
group:staff:rw-p--aARWc---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--aARWc--s:-------:allow
everyone@:------a-R-c--s:-------:allow