1. Oracle Solaris ZFS File System (Introduction)
2. Getting Started With Oracle Solaris ZFS
3. Oracle Solaris ZFS and Traditional File System Differences
4. Managing Oracle Solaris ZFS Storage Pools
5. Installing and Booting an Oracle Solaris ZFS Root File System
6. Managing Oracle Solaris ZFS File Systems
7. Working With Oracle Solaris ZFS Snapshots and Clones
8. Using ACLs to Protect Oracle Solaris 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
9. Oracle Solaris ZFS Delegated Administration
10. Oracle Solaris ZFS Advanced Topics
11. Oracle Solaris ZFS Troubleshooting and Pool Recovery
Previous versions of the Solaris OS supported an ACL implementation that was primarily based on the POSIX-draft ACL specification. The POSIX-draft based ACLs are used to protect UFS files and are translated by versions of NFS prior to NFSv4.
With the introduction of NFSv4, a new ACL model fully supports the interoperability that NFSv4 offers between UNIX and non-UNIX clients. The new ACL implementation, as defined in the NFSv4 specification, provides much richer semantics that are based on NT-style ACLs.
The main differences of the new ACL model follow:
The new ACL model is based on the NFSv4 specification and is similar to NT-style ACLs.
The new model provides a much more granular set of access privileges. For more information, see Table 8-2.
ACLs are set and displayed with the chmod and ls commands rather than the setfacl and getfacl commands.
The new model provides richer inheritance semantics for designating how access privileges are applied from a directory to subdirectories, and so on. For more information, see ACL Inheritance.
Both ACL models provide more fine-grained access control than is available with the standard file permissions. Much like POSIX-draft ACLs, the new ACLs are composed of multiple Access Control Entries (ACEs).
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. As such, you cannot infer from any single ACE that defines a set of permissions whether the permissions that weren't defined in that ACE are allowed or denied.
Translation between NFSv4 ACLs and POSIX-draft ACLs is as follows:
If you use an ACL-aware utility, such as the cp, mv, tar, cpio, or rcp command, to transfer UFS files with ACLs to a ZFS file system, the POSIX-draft ACLs are translated into the equivalent NFSv4 ACLs.
Some NFSv4 ACLs are translated into POSIX-draft ACLs. You see a message similar to the following if an NFSv4 ACL isn't translated into a POSIX-draft ACL:
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea
If you create a UFS tar or cpio archive with the preserve ACL option (tar -p or cpio -P) on a system that runs a current Solaris release, you will lose the ACLs when the archive is extracted on a system that runs a previous Solaris release.
All of the files are extracted with the correct file modes, but the ACL entries are ignored.
You can use the ufsrestore command to restore data into a ZFS file system. If the original data includes POSIX-draft ACLs, they are translated into to NFSv4 ACLs.
If you attempt to set an NFSv4 ACL on a UFS file, you see a message similar to the following:
chmod: ERROR: ACL type's are different
If you attempt to set a POSIX-draft ACL on a ZFS file, you see messages similar to the following:
# getfacl filea File system doesn't support aclent_t style ACL's. See acl(5) for more information on Solaris ACL support.
For information about other limitations with ACLs and backup products, see Saving ZFS Data With Other Backup Products.
Syntax for Setting Trivial ACLs
An ACL is trivial in that it only represents the traditional UNIX owner/group/other entries.
chmod [options] A[index]{+|=}owner@ |group@ |everyone@:access-permissions/...[:inheritance-flags]:deny | allow file
chmod [options] A-owner@, group@, everyone@:access-permissions/...[:inheritance-flags]:deny | allow file ...
chmod [options] A[index]- file
Syntax for Setting Non-Trivial ACLs
chmod [options] A[index]{+|=}user|group:name:access-permissions/...[:inheritance-flags]:deny | allow file
chmod [options] A-user|group:name:access-permissions/...[:inheritance-flags]:deny | allow file ...
chmod [options] A[index]- file
Identifies the ACL-entry-type for trivial ACL syntax. For a description of ACL entry types, see Table 8-1.
Identifies the ACL-entry-type for explicit ACL syntax. The user and group ACL-entry-type must also contain the ACL-entry-ID, username or groupname. For a description of ACL entry types, see Table 8-1.
Identifies the access permissions that are granted or denied. For a description of ACL access privileges, see Table 8-2.
Identifies an optional list of ACL inheritance flags. For a description of the ACL inheritance flags, see Table 8-3.
Identifies whether the access permissions are granted or denied.
In the following example, the ACL-entry-ID value is not relevant:
group@:write_data/append_data/execute:deny
The following example includes an ACL-entry-ID because a specific user (ACL-entry-type) is included in the ACL.
0:user:gozer:list_directory/read_data/execute:allow
When an ACL entry is displayed, it looks similar to the following:
2:group@:write_data/append_data/execute:deny
In this example, the 2, known as the index-ID designation, identifies the ACL entry in the larger ACL, which might have multiple entries for owner, specific UIDs, group, and everyone. You can specify the index-ID with the chmod command to identify which part of the ACL you want to modify. For example, you can identify index ID 3 as A3 in the chmod command syntax, similar to the following:
chmod A3=user:venkman:read_acl:allow filename
ACL entry types, which are the ACL representations of owner, group, and other, are described in the following table.
Table 8-1 ACL Entry Types
|
ACL access privileges are described in the following table.
Table 8-2 ACL Access Privileges
|
The purpose of using ACL inheritance is so that a newly created file or directory can inherit the ACLs they are intended to inherit, but without disregarding the existing permissions on the parent directory.
By default, ACLs are not propagated. If you set a non-trivial ACL on a directory, it is not inherited by any subsequent directory. You must specify the inheritance of an ACL on a file or directory.
The optional inheritance flags are described in the following table.
Table 8-3 ACL Inheritance Flags
|
In addition, you can set a default ACL inheritance policy on a file system that is more strict or less strict by using the aclinherit file system property. For more information, see the next section.
A ZFS file system has 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 new file or directory is equal to the permissions of the file or directory.
noallow – For new objects, only inheritable ACL entries that have an access type of deny are inherited.
restricted – For new objects, the write_owner and write_acl permissions are removed when an ACL entry is inherited.
passthrough – When the property value is set to passthrough, files are created with permissions determined by the inheritable ACEs. If no inheritable ACEs exist that affect the permissions, then the permissions are set in accordance to the requested permissions from the application.
passthrough-x – This property value has the same semantics as passthrough, except that when passthrough-x is enabled, files are created with the execute (x) permission, but only if the execute permission is set in the file creation mode and in an inheritable ACE that affects the mode.
The default value for the aclinherit property is restricted.
aclmode – This property modifies ACL behavior when a file is initially created or whenever a file or directory's permissions are modified by the chmod command. Values include the following:
discard – All ACL entries are removed except for the entries 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 permissions, 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 the owner permissions.
passthrough – During a chmod operation, ACEs other than owner@, group@, or everyone@ are not modified in any way. ACEs with owner@, group@, or everyone@ are disabled to set the file mode as requested by the chmod operation.
The default value for the aclmode property is groupmask.