Table of Contents
Recent 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:
Based on the NFSv4 specification and similar to NT-style ACLs.
Provide much more granular set of access privileges. For more information, see Table 7–2.
Set and displayed with the chmod and ls commands rather than the setfacl and getfacl commands.
Provide richer inheritance semantics for designating how access privileges are applied from 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 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:
If you use any ACL-aware utility, such as the cp, mv, tar, cpio, or rcp commands, to transfer UFS files with ACLs to a ZFS file system, the POSIX-draft ACLs are translated into the equivalent NFSv4-style ACLs.
Some NFSv4-style ACLs are translated to POSIX-draft ACLs. You see a message similar to the following if an NFSv4–style ACL isn't translated to 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, but the ACLs will be lost.
If you attempt to set an NFSv4-style 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-style ACL on a ZFS file, you will 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.
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 Explicit ACLs
chmod [options] A[index]{+|=}user|group:
access-permissions/...[:inheritance-flags]:deny | allow file
chmod [options] A-user|group:
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 7–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 7–1.
Identifies the access permissions that are granted or denied. For a description of ACL access privileges, see Table 7–2.
Identifies an optional list of ACL inheritance flags. For a description of the ACL inheritance flags, see Table 7–3.
deny | allow
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
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 |
|---|---|
|
|
Specifies the access granted to the owner of the object. |
|
|
Specifies the access granted to the owning group of the object. |
|
|
Specifies the access granted to any user or group that does not match any other ACL entry. |
|
|
With a user name, specifies the access granted to an additional user
of the object. Must include the ACL-entry-ID, which contains
a |
|
|
With a group name, specifies the access granted to an additional group
of the object. Must include the ACL-entry-ID, which contains
a |
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 |
Permission to create a subdirectory in a directory. |
|
append_data |
p |
On a file, permission to modify the contents of a file. |
|
delete |
d |
Permission to delete a file. |
|
delete_child |
D |
Permission to delete a file or directory within a directory. |
|
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 |
|
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 |
Placeholder, not used at this time. |
|
write_xattr |
A |
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 |
W |
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 |
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 an explicit 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.3. 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 |
|
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 |
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.
The ZFS file system includes two property modes 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 is 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 for the aclinherit 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 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 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 for the aclmode property is groupmask.