|HP-UX Reference > A
HP-UX 11i Version 3: February 2007
acl — introduction to HFS access control lists (ACLs)
Access control lists are a key enforcement mechanism of discretionary access control (see Definitions below), for specifying access to files by users and groups more selectively than traditional HP-UX mechanisms allow.
HP-UX already enables nonprivileged users or processes, such as file owners, to allow or deny other users access to files and other objects on a "need to know" basis, as determined by their user and/or group identity (see passwd(4) and group(4)). This level of control is accomplished by setting or manipulating a file's permission bits to grant or restrict access by owner, group, and others (see chmod(2)).
ACLs offer a greater degree of selectivity than permission bits. ACLs allow the file owner or superuser to permit or deny access to a list of users, groups, or combinations thereof.
ACLs are supported as a superset of the UNIX operating system discretionary access control (DAC) mechanism for files, but not for other objects such as interprocess communication (IPC) objects.
This manpage describes ACLs as implemented on HFS file systems only. See aclv(5) for a description of ACLs in JFS file systems.
Because control of access to data is a key concern of computer security, we provide the following definitions, based on those of the Department of Defense Trusted Computer System Evaluation Criteria, to explain further both the concepts of access control and its relevance to HP-UX security features:
Access Control List Entries
An access control list (ACL) consists of sets of (user.group ,mode) entries associated with a file that specify permissions. Each entry specifies for one user-ID/group-ID combination a set of access permissions, including read, write, and execute/search.
To help understand the relationship between access control lists and traditional file permissions, consider the following file and its permissions:
-rwxr-xr-- james admin datafile
In an ACL, user and group IDs can be represented by names or numbers, found in /etc/passwd. The following special symbols can also be used:
Base ACL Entries
When a file is created, three base access control list entries are mapped from the file's access permission bits to match a file's owner and group and its traditional permission bits. Base ACL entries can be changed by the chmod(2) and setacl(2) system calls.
(Except where noted, examples are represented in short form notation. See ACL Notation, below.)
Optional ACL entries
Optional access control list entries contain additional access control information, which the user can set with the setacl(2) system call to further allow or deny file access. Up to thirteen additional user/group combinations can be specified.
For example, the following optional access control list entries can be associated with our file:
Supported library calls and commands that manage ACLs recognize three different symbolic representations:
For our example file, the base ACL entries could be represented in the three notations as follows:
In addition to basic ACL usage, some library calls and commands understand and use a variation of operator and short forms. See the section below on ACL Patterns.
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:
Once an entry for the combination of a process effective user ID and effective group ID (or any supplementary 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 nonnull 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 ORed 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:
An operator is always required in each entry. Operators are:
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 particular order.
Note that chmod(1) allows only u, g, o, or a 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 convenience.
The exact syntax is:
acl ::= [entry[,entry]...] entry ::= id . id op mode [op mode]... id ::= name | number | % | @ op ::= = | + | - mode ::= 0..7 | [char[char]...] char ::= r | w | x
Short Form of ACLs (input and output)
(user . group, mode) ...
Short form differs from operator form in several ways:
Multiple entries are concatenated. For consistency with operator form, a dot (.) is used to separate user and group IDs.
On output, no whitespace is printed except in names (if any). ID numbers are printed if no matching names are known. Either ID can be printed as % for "no specific user or group." The mode is represented as <r|-><w|-><x|->, that is, it always has three characters, padded with hyphens for unset mode bits. If the ACL is read from the system, entries are ordered by specificity, then by numeric values of ID parts.
On input, 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.
User and group IDs are represented as in operator form.
The mode is represented by an octal value of 0 through 7; or any combination of r, w, x and - (ignored) can be given in any order (see EXAMPLES below). A null mode denies access.
Redundancy does not result in error; the last entry for any user-ID/group-ID combination takes effect. Entries need not appear in any particular order.
The exact syntax is:
acl ::= [entry[entry]...] entry ::= (id.id,mode) id ::= name | number | % | @ mode ::= 0..7 | [char[char]...] char ::= r | w | x | -
Long Form of ACLs (output only)
mode user . group
Each entry occupies a single line of output. The mode appears first in a fixed-width field, using hyphens (for unset mode bits) for easy vertical scanning. Each user and group ID is shown as a name if known, a number if unknown, or % for "no specific user or group." Entries are ordered from most to least specific, then by numeric values of ID parts.
Note that every ACL printed has at least three entries, the base ACL entries (that is, uid.%, %.gid, and %.%).
The exact syntax is:
acl ::= entry[<newline>entry]... entry ::= mode<space>id.id mode ::= <r|-><w|-><x|-> id ::= name | number | %
Some library calls and commands recognize and use ACL patterns instead of exact ACLs to allow operations on all entries that match the patterns. ACL syntax is extended in the following ways:
ACL Operations Supported
The system calls setacl(2) and getacl(2) allow setting or getting the entire ACL for a file in the form of an array of acl_entry structures. To check access rights to a file, see access(2) and getaccess(2).
Various library calls are provided to manage ACLs:
The following commands are available to manage ACLs and permissions:
ACL Interaction with stat, chmod, and chown
The following sets the %.% entry to restrict "other" users to only reading the file.
chacl '%.% = r' myfile
The following allows user "bill" in any group to write the file, assuming that no restrictive entry is more specific than the bill.% entry (for example, a bill.adm entry that denies writing).
chacl 'bill.% +w' myfile
The following ACL specification contains two entries. The first one deletes write and adds read capability to the entry for user 12, group 4. The second entry denies access for any unspecified user in any unspecified group.
chacl '12.4-w+r, %.% =' myfile
The following pair of entries sets the u.% entry for the file's owner to allow both read and execute and results in adding write and execute capabilities for "other" users (the "%.%" entry). Note that a mode character is purposely repeated for illustration purposes.
chacl '@.% = 5, %.% + xwx' myfile
Here is a typical ACL as it might be printed. It allows user jpc to read or execute the file while in group adm; it denies user ajs access to the file while in group trux; it allows user jpc in any group (except adm) to only read the file; any other user in group bin may read or execute the file; and any other user may only read the file.
The following allows "other" users to only read the file.
chacl '(%.%,r)' myfile
The following sets write-only access for user bill in any group.
chacl '(bill.%,-w-)' myfile
The following sets the entry for user 12 in group 4 to allow read and write.
chacl '(12.4,wr)' myfile
The following sets the base ACL entry for the file's owner to allow both read and execute, and sets write and execute capabilities for "other" users (the "%.%" entry).
chacl '(@.%, 5) (%.%, xwx)' myfile
Here is the same ACL as in an earlier example, printed in long form.
r-x jpc.adm --- ajs.trux r-- jpc.% r-x %.bin r-- %.%
The following command locates files whose ACLs contain an entry that allows read access and denies write access to some user/group combination.
find / -acl '*.*+r-w' -print
The following matches entries for any user in group bin and for user tammy in any group, regardless of the entries' mode values. Matching optional ACL entries are deleted and mode values in matching base ACL entries are set to zero:
chacl -d '%.bin, tammy.*=*' myfile
The following matches all entries, deleting optional entries and setting mode values of base ACL entries to zero:
chacl -d '(*.*,*)' myfile
The <sys/acl.h> header file defines the following constants to govern the numbers of entries per ACL:
The ACL entry structure structacl_entry is also defined, and includes the following members:
aclid_t uid; /* user ID */ aclid_t gid; /* group ID */ aclmode_t mode; /* see <unistd.h> */
The <sys/acl.h> header also defines the types aclid_t and aclmode_t.
Non-specific user and group ID values:
A special nentries value ACL_DELOPT is used with setacl(2) to delete optional entries.
The <sys/getaccess.h> header defines constants for use with getaccess(2).
Special parameter values for uid:
Special parameter values for ngroups:
The <acllib.h> header file defines several constants for use with ACL support library calls.
Symbolic forms of ACLs for acltostr():
Magic values for various calls:
ACL_FILEOWNER file's owner ID ACL_FILEGROUP file's group ID ACL_ANYUSER wildcard user ID ACL_ANYGROUP wildcard group ID MODE_DEL delete one ACL entry
Mask for valid mode bits in ACL entries:
MODEMASK (R_OK | W_OK | X_OK)
The <acllib.h> header also defines the struct acl_entry_patt ACL pattern entry structure, which includes the following members:
aclid_t uid; /* user ID */ aclid_t gid; /* group ID */ aclmode_t onmode; /* mode bits that must be on */ aclmode_t offmode; /* mode bits that must be off */
ACLs are intended for use on ordinary files and directories. Optional ACL entries are not recommended on files that are manipulated by certain system utilities, such as terminal special files and LP scheduler control files. These utilities might delete optional entries, including those whose intent is restrictive, without warning as a consequence of calling chmod(2), thereby increasing access unexpectedly.
Most, but not all, supported utilities are able to handle ACLs correctly. However, only the fbackup(1M) and frecover(1M) file archive utilities handle access control lists properly. When using programs (such as archive programs ar(1), cpio(1), ftio(1), tar(1), and dump(1M)) unable to handle ACLs on files with optional ACL entries, note the Access Control List information included on their respective reference pages, to avoid loss of data.
If a user name is defined in the /etc/passwd file or a group name is defined in the /etc/group file as % or @, or for patterns, *, ACL syntax cannot reference that name as itself because the symbols have other meanings. However, such users or groups can still be referenced by their ID numbers. User and/or group names must not include the following characters:
It is possible to specify an ACL pattern using the @ (file owner or group) or * (wildcard) symbols so that it cannot match certain files, perhaps depending on their ownership, by giving two entries, one with specific values and the other using @ or *, which are equivalent for a file but contain different mode values. For example:
find / -acl '(ajs.%,r)(@.%,rw)' -print
cannot match a file owned by ajs.
NFS does not support ACLs on remote files. Individual manual entries specify the behavior of various system calls, library calls, and commands under these circumstances. Be careful when transferring a file with optional entries over a network or when manipulating a remote file because optional entries may be silently deleted.
chacl(1), chmod(1), cp(1), find(1), getaccess(1), ln(1), ls(1), lsacl(1), mv(1), rm(1), fbackup(1M), frecover(1M), fsck(1M), fsdb(1M) access(2), chmod(2), chown(2), creat(2), getaccess(2), getacl(2), mknod(2), open(2), setacl(2), stat(2), acltostr(3C), chownacl(3C), cpacl(3C), setaclentry(3C), strtoacl(3C), group(4), passwd(4), privgrp(4), aclv(5).