acl.5 (2010 09)

a
acl(5) acl(5)
ACL Uniqueness
Entries are unique in each ACL. There can only be one (u.g, mode) entry for any pair of u and g values;
one (u.%, mode) entry for a given value of u; one (%.g, mode) entry for a given value of g; and one (%.%,
mode) entry for each file. For example, an ACL can have a (23.14, mode) entry and a (23.%, mode)entry,
but not two (23.14, mode) entries or two (23.%, mode)entries.
Access Check Algorithm
ACL entries can be categorized by four levels of specificity. In access checking, ACLs are compared to the
effective user and group IDs in this order:
(u.g, rwx) specific user, specific group
(u.%, rwx) specific user, no specific group
(%.g, rwx) no specific user, specific group
(%.%, rwx) no specific user, no specific group
Once an entry for the combination of a process effective user ID and effective group ID (or any supple-
mentary group ID) is matched, no further (that is, less specific) entries are checked. More specific entries
that match take precedence over any less specific ones that also match.
If a process has more than one group ID (that is, a non-null supplementary groups list), more than one
(u.g, mode) or (%.g, mode) entry might apply for that process. If so, the access modes in all matching
entries (of the same level of specificity, u.g or %.g) are OR’d together. Access is granted if the resulting
mode bits allow it. Since entries are unique, the order of entries in each entry type is insignificant.
Because the traditional UNIX permission bits are mapped into base ACL entries, they are included in
access checks.
If a request is made for more than one type of access, such as opening a file for both reading and writing,
access is granted only if the process is allowed all requested types of access. Note that access can be
granted if the process has two groups in its groups list, one of which is only allowed read access, and the
other of which is only allowed write access. In other words, even if the requested access is not granted by
any one entry, it may be granted by a combination of entries due to the process belonging to several
groups.
Operator Form of ACLs (input only)
user. group operator mode [ operator mode ]... , ...
Multiple entries are separated by commas, as in chmod(1). Each entry consists of a user identifier and
group identifier followed by one or more operators and mode characters, as in the mode syntax accepted
by chmod(1).
The entire ACL must be a single argument, and thus should be quoted to the shell if it contains whi-
tespace or special characters. Whitespace is ignored except within names. A null ACL is legitimate, and
means either "no access" or "no changes", depending on context.
Each user or group ID may be represented by:
name Valid user or group name.
number Valid numeric ID value.
% "No specific user or group," as appropriate.
@ "Current file owner or group," as appropriate; useful for referring to a file’s u.% and %.g
base ACL entries.
An operator is always required in each entry. Operators are:
= Set all bits in the entry to the given mode value.
+ Set the indicated mode bits in the entry.
- Clear the indicated mode bits in the entry.
The mode is represented by an octal value of
0 through 7; or any combination of r, w, and x can be
given in any order (see EXAMPLES below). A null mode denies access if the operator is =,orrepresents
"no change" if the operator is + or -.
Multiple entries and multiple operator-mode parts in an entry are applied in the order specified.
Conflicts do not result in error; the last specified entry or operator takes effect. Entries need not appear
in any particular order.
Note that chmod(1) allows only
u, g, o,ora to refer symbolically to the file owner, group, other, or all
users, respectively. Since ACLs work with arbitrary user and group identifiers, @ is provided as a con-
venience.
HP-UX 11i Version 3: September 2010 − 3 − Hewlett-Packard Company 3