JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: ZFS File Systems     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Oracle Solaris ZFS File System (Introduction)

2.  Getting Started With Oracle Solaris ZFS

3.  Managing Oracle Solaris ZFS Storage Pools

4.  Managing ZFS Root Pool Components

5.  Managing Oracle Solaris ZFS File Systems

6.  Working With Oracle Solaris ZFS Snapshots and Clones

7.  Using ACLs and Attributes to Protect Oracle Solaris ZFS Files

Solaris ACL Model

Syntax Descriptions for Setting ACLs

ZFS ACL Sets

ACL Inheritance

ACL Properties

Setting ACLs on ZFS Files

Setting and Displaying ACLs on ZFS Files in Verbose Format

Setting ACL Inheritance on ZFS Files in Verbose Format

Setting and Displaying ACLs on ZFS Files in Compact Format

Applying Special Attributes to ZFS Files

8.  Oracle Solaris ZFS Delegated Administration

9.  Oracle Solaris ZFS Advanced Topics

10.  Oracle Solaris ZFS Troubleshooting and Pool Recovery

11.  Archiving Snapshots and Root Pool Recovery

12.  Recommended Oracle Solaris ZFS Practices

A.  Oracle Solaris ZFS Version Descriptions

Index

Setting ACLs on ZFS Files

As implemented with ZFS, ACLs are composed of an array of ACL entries. ZFS provides a pure ACL model, where all files have an ACL. Typically, the ACL is trivial in that it only represents the traditional UNIX owner/group/other entries.

ZFS files still have permission bits and a mode, but these values are more of a cache of what the ACL represents. As such, if you change the permissions of the file, the 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 group or everyone. All access control decisions are governed by the permissions represented in a file or directory's ACL.

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

If you set a non-trivial ACL on a directory, the ACL is not automatically inherited by the directory's children. If you set an non-trivial ACL and you want it inherited to the directory's children, you have to use the ACL inheritance flags. For more information, see Table 7-4 and Setting ACL Inheritance on ZFS Files in Verbose Format.

When you create a new file and depending on the umask value, a default trivial ACL, similar to the following, is applied:

$ ls -v file.1
-rw-r--r--   1 root     root      206663 Jun 23 15:06 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/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Each user category (owner@, group@, everyone@) has an ACL entry in this example.

A description of this file ACL is as follows:

0:owner@

The owner can read and modify the contents of the file (read_data/write_data/append_data/read_xattr). The owner can also modify the file's attributes such as timestamps, extended attributes, and ACLs (write_xattr/read_attributes/write_attributes/read_acl/write_acl). In addition, the owner can modify the ownership of the file (write_owner:allow).

The synchronize access permission is not currently implemented.

1:group@

The group is granted read permissions to the file and the file's attributes (read_data/read_xattr/read_attributes/read_acl:allow).

2:everyone@

Everyone who is not user or group is granted read permissions to the file and the file's attributes (read_data/read_xattr/read_attributes/read_acl/synchronize:allow). The synchronize access permission is not currently implemented.

When a new directory is created and depending on the umask value, a default directory ACL is similar to the following:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 Jul 20 13:44 dir.1
     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

A description of this directory ACL is as follows:

0:owner@

The owner can read and modify the directory contents (list_directory/read_data/add_file/write_data/add_subdirectory/append_data) and read and modify the file's attributes such as timestamps, extended attributes, and ACLs (/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl). In addition, the owner can search the contents (execute), delete a file or directory (delete_child), and can modify the ownership of the directory (write_owner:allow).

The synchronize access permission is not currently implemented.

1:group@

The group can list and read the directory contents and the directory's attributes. In addition, the group has execute permission to search the directory contents (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow).

2:everyone@

Everyone who is not user or group is granted read and execute permissions to the directory contents and the directory's attributes (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow). The synchronize access permission is not currently implemented.