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

Solaris ACL Model

Previous versions of Solaris 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 are as follows:

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 style ACLs use a single entry to define what permissions are allowed and what 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 or not the permissions that weren't defined in that ACE are allowed or denied.

Translation between NFSv4-style ACLs and POSIX-draft ACLs is as follows:

For information about other limitations with ACLs and backup products, see Saving ZFS Data With Other Backup Products.

Syntax Descriptions for Setting ACLs

Two basic ACL formats are provided as follows:

Syntax for Setting Trivial ACLs

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

owner@, group@, everyone@

Identifies the ACL-entry-type for trivial ACL syntax. For a description of ACL-entry-types, see Table 7-1.

user or group:ACL-entry-ID=username or groupname

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 7-1.

access-permissions/.../

Identifies the access permissions that are granted or denied. For a description of ACL access privileges, see Table 7-2.

inheritance-flags

Identifies an optional list of ACL inheritance flags. For a description of the ACL inheritance flags, see Table 7-4.

deny | allow

Identifies whether the access permissions are granted or denied.

In the following example, no ACL-entry-ID value exists for owner@, group@, or everyone@..

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

The 2 or the index-ID designation in this example 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 to the chmod command, 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 7-1 ACL Entry Types

ACL Entry Type
Description
owner@
Specifies the access granted to the owner of the object.
group@
Specifies the access granted to the owning group of the object.
everyone@
Specifies the access granted to any user or group that does not match any other ACL entry.
user
With a user name, specifies the access granted to an additional user of the object. Must include the ACL-entry-ID, which contains a username or userID. If the value is not a valid numeric UID or username, the ACL entry type is invalid.
group
With a group name, specifies the access granted to an additional group of the object. Must include the ACL-entry-ID, which contains a groupname or groupID. If the value is not a valid numeric GID or groupname, the ACL entry type is invalid.

ACL access privileges are described in the following table.

Table 7-2 ACL Access Privileges

Access Privilege
Compact Access Privilege
Description
add_file
w
Permission to add a new file to a directory.
add_subdirectory
p
On a directory, permission to create a subdirectory.
append_data
p
Not currently implemented.
delete
d
Permission to delete a file. For more information about specific delete permission behavior, see Table 7-3.
delete_child
D
Permission to delete a file or directory within a directory. For more information about specific delete_child permission behavior, see Table 7-3.
execute
x
Permission to execute a file or search the contents of a directory.
list_directory
r
Permission to list the contents of a directory.
read_acl
c
Permission to read the ACL (ls).
read_attributes
a
Permission to read basic attributes (non-ACLs) of a file. Think of basic attributes as the stat level attributes. Allowing this access mask bit means the entity can execute ls(1) and stat(2).
read_data
r
Permission to read the contents of the file.
read_xattr
R
Permission to read the extended attributes of a file or perform a lookup in the file's extended attributes directory.
synchronize
s
Not currently implemented.
write_xattr
W
Permission to create extended attributes or write to the extended attributes directory.

Granting this permission to a user means that the user can create an extended attribute directory for a file. The attribute file's permissions control the user's access to the attribute.

write_data
w
Permission to modify or replace the contents of a file.
write_attributes
A
Permission to change the times associated with a file or directory to an arbitrary value.
write_acl
C
Permission to write the ACL or the ability to modify the ACL by using the chmod command.
write_owner
o
Permission to change the file's owner or group. Or, the ability to execute the chown or chgrp commands on the file.

Permission to take ownership of a file or permission to change the group ownership of the file to a group of which the user is a member. If you want to change the file or group ownership to an arbitrary user or group, then the PRIV_FILE_CHOWN privilege is required.

The following table provides additional details about ACL delete and delete_child behavior.

Table 7-3 ACL delete and delete_child Permission Behavior

Parent Directory Permissions
Target Object Permissions
ACL allows delete
ACL denies delete
Delete permission unspecified
ACL allows delete_child
Permit
Permit
Permit
ACL denies delete_child
Permit
Deny
Deny
ACL allows only write and execute
Permit
Permit
Permit
ACL denies write and execute
Permit
Deny
Deny

ZFS ACL Sets

The following ACL combinations can be applied in an ACL set rather than setting individual permissions separately. The following ACL sets are available.

ACL Set Name
Included ACL Permissions
full_set
All permissions
modify_set
all permissions except write_acl and write_owner
read_set
read_data, read_attributes, read_xattr, and read_acl
write_set
write_data, append_data, write_attributes, and write_xattr

These ACL sets are prefined and cannot be modified.

ACL Inheritance

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 permission bits on the parent directory.

By default, ACLs are not propagated. If you set a non-trivial ACL on a directory, it is not inherited to 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 7-4 ACL Inheritance Flags

Inheritance Flag
Compact Inheritance Flag
Description
file_inherit
f
Only inherit the ACL from the parent directory to the directory's files.
dir_inherit
d
Only inherit the ACL from the parent directory to the directory's subdirectories.
inherit_only
i
Inherit the ACL from the parent directory but applies only to newly created files or subdirectories and not the directory itself. This flag requires the file_inherit flag, the dir_inherit flag, or both, to indicate what to inherit.
no_propagate
n
Only inherit the ACL from the parent directory to the first-level contents of the directory, not the second-level or subsequent contents. This flag requires the file_inherit flag, the dir_inherit flag, or both, to indicate what to inherit.
-
N/A
No permission granted.
Currently, the following flags are only applicable to a SMB client or server.
successful_access
S
Indicates whether an alarm or audit record should be initiated upon a successful access. This flag is used with audit or alarm ACE types.
failed_access
F
Indicates whether an alarm or audit record should be initiated when an access fails. This flag is used with audit or alarm ACE types.
inherited
I
Indicates that an ACE was inherited.

In addition, you can set a default ACL inheritance policy on the file system that is more strict or less strict by using the aclinherit file system property. For more information, see the next section.

ACL Properties

The ZFS file system includes the following ACL properties to determine the specific behavior of ACL inheritance and ACL interaction with chmod operations.