HP-UX Reference (11i v1 05/09) - 5 Miscellaneous Topics (vol 9)

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 supplemen-
tary 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 whitespace
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 =, or represents "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 par-
ticular 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 conveni-
ence.
Section 5−−4 Hewlett-Packard Company − 3 − HP-UX 11i Version 1: September 2005