7.1.2 ACL Inheritance
The purpose of using ACL inheritance is for a newly created file or directory
to inherit the ACLs they are intended to inherit, but without disregarding the existing
permission bits on the parent directory.
By default, ACLs are not propagated. If you set an explicit ACL on a directory
it is not inherited to any subsequent directory. You have to specify the inheritance
of an ACL on a file or directory.
The optional inheritance flags are described in the following table.
Table 7-3 ACL Inheritance Flags
Inheritance Flag | Description |
|---|
file_inherit | Inherit the ACL from the parent directory to the directory's files only. |
dir_inherit | Inherit the ACL from the parent directory to the directory's subdirectories
only. |
inherit_only | Inherit the ACL from the parent directory but only applies to newly created
files or subdirectories and not the directory itself. This flag requires either the
file_inherit and/or dir_inherit flags to indicate what to inherit. |
no_propagate | Inherit the ACL from the parent directory to the first-level contents of the
directory only, not the second-level or subsequent contents. This flag requires either
the file_inherit and/or dir_inherit flags to indicate what to inherit. |
In addition, you can set a default ACL inheritance policy on the file system
that is strict or less strict by using the aclinherit file system
property. For more information, see the next section.
7.1.3 ACL Property Modes
The ZFS file system includes two properties related to ACLs:
aclinherit - This property determines the behavior of ACL inheritance.
Values include the following:
discard - For new objects, no ACL entries are inherited when
a file or directory is created. The ACL on the file or directory will be equal to
the permission mode of the file or directory.
noallow - For new objects, only inheritable ACL entries that
have an access type of deny are inherited.
secure - For new objects, the write_owner and write_acl permissions are removed when an ACL entry is inherited.
passthrough - For new objects, the inheritable ACL entries are
inherited with no changes made to the them. This mode, in effect, disables secure
mode.
The default mode is secure.
aclmode - This property modifies ACL behavior whenever a file
or directory's mode is modified by the chmod command or when a
file is initially created. Values include the following:
discard - All ACL entries are removed except for those needed
to define the mode of the file or directory.
groupmask - User or group ACL permissions are reduced so that
they are no greater than the group permission bits unless it is a user entry that
has the same UID as the owner of the file or directory. Then, the ACL permissions
are reduced so that they are no greater than owner permission bits.
passthrough - For new objects, the inheritable ACL entries are
inherited with no changes made to the them.
The default mode is groupmask.
7.2 Using 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 they are more of a cache
of what the ACL represents. This means that if you change the permissions of the file,
the file's ACL is updated accordingly. In addition, if you remove an explicit 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 granting
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:
Each ACL entry is processed in order by ZFS.
Only ACL entries that have a "who" that matches the requester
of the access are processed.
Each ACL entry is processed until all the bits of the access request
have been allowed.
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 it 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 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.
If you set an explicit ACL on a directory, the ACL is not automatically inherited
to the directory's children. If you set an explicit 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-3 and 7.3.1 Setting ACL Inheritance on ZFS Files.
When a new file is created and depending on the umask value,
a default trivial ACL is applied, which is similar to the following:
% ls -v file.1
-rw-r--r-- 1 root root 2703 Nov 4 12:37 file.1
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
:allow
|
Note that in the above example, each user category (owner@, group@, everyone@)
has two ACL entries, which is one entry for deny permissions and one entry is for
access permissions.
A description of this file ACL is as follows:
| 0:owner@ | Owner is denied execute permissions to the file (execute:deny).
| | 1:owner@ | Owner can read and modify the contents of the file (read_data/write_data/append_data) and modify the file's attributes such as time stamps, extended attributes,
and ACLs (write_xattr/write_attributes /write_acl). In addition,
the owner is granted the ability to modify the ownership of the file (write_owner:allow)
| | 2:group@ | Group is denied modify and execute permissions to the file (write_data/append_data/execute:deny).
| | 3:group@ | Group is granted read permissions to the file (read_data:allow).
| | 4:everyone@ | Everyone who is not user or group is denied permission to execute
or modify the contents of the file and to modify any attributes of the file (write_data/append_data/write_xattr/execute/write_attributes/write_acl/write_owner:deny).
| | 5: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 Nov 1 14:51 dir.1
0:owner@::deny
1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
2:group@:add_file/write_data/add_subdirectory/append_data:deny
3:group@:list_directory/read_data/execute:allow
4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny
5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow
|
| 
Previous