|HP-UX Reference > A
HP-UX 11i Version 3: February 2007
aclv — introduction to JFS access control lists (ACLs)
Access control lists (ACLs) 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 and groups other than the file owner and owning group.
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 JFS file systems only. See acl(5) for a description of ACLs in HFS 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 a set of one-line entries associated with a file that specify permissions. Each entry specifies for one user-ID or 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.
Supported commands that manage JFS ACLs recognize the following symbolic representation:
An ACL entry prefixed with d: or default:, can occur only in a directory's ACL, and it indicates that the remainder of the entry is not to be used in determining the access rights to the directory, but is instead to be applied to any files or subdirectories created in the directory (see ACL Inheritance, below).
The uid and gid fields contain either numeric user or group IDs, or their corresponding character strings from /etc/passwd or /etc/group. The perm field indicates access permission either in symbolic form, as a combination of r, w, x and -, or in numeric form, as an octal value of 0 through 7 representing the sum of 4 for read permission, 2 for write permission and 1 for execute permission.
Base ACL Entries
When a file is created, four 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. This is known as a "minimal ACL". Base ACL entries can be changed by the chmod(2) and acl(2) system calls.
When an ACL is minimal, i.e., it has no optional ACL entries (see next section), then the group and class permissions are exactly equal.
Optional ACL entries
Optional access control list entries contain additional access control information, which the user can set with the acl(2) system call to further allow or deny file access. Up to thirteen optional ACL entries can be specified.
For example, the following optional access control list entries can be associated with our file:
In an ACL that contains more than one user entry and/or more than one group entry, the class entry specifies the maximum permissions that can be granted by any of the additional user and group entries. If a particular permission is not granted in the class entry, then it cannot be granted by any ACL entries (except for the first user [owner] entry and the other entry). Any permission can be denied to a particular user or group. The class entry acts as a upper bound for file permissions.
When an ACL contains more than one user and/or group entry, the collection of additional user and group entries are referred to as the group class entries, since the effective permission granted by any of these additional entries is limited by the class entry.
If there are additional entries in the ACL, the class entry will no longer necessarily equal the value of the permission for the owning group as reported by ls -l. This feature is useful because it means that the chmod(1) command can usefully affect the permissions of a file that has additional ACL entries.
Entries are unique in each ACL. There can be only one of each type of base entry, and one entry for any given user or group ID. Likewise, there can be only one of each type of default base entry, and one default entry for any given user or group ID.
When a directory's ACL contains default entries, those entries are not used in determining access to the directory itself. Instead, every time a file is created in the directory, the directory's default ACL entries are added as non-default ACL entries to the new file.
For example, suppose the directory /a has the following ACL, as reported by getacl(1):
# file: /a # owner: alpha # group: uno user::rwx group::rwx class:rwx other:rwx default:user:beta:r-- default:user:gamma:r-- default:group:dos:--- default:group:tres:---
Then, any new file created in /a would have its ACL initialized using a combination of the creator's umask (e.g., 022) and the directory's default ACL entries as follows:
# file: /a/file # owner: creator_uid # group: creator_gid user::rw- user:beta:r-- user:gamma:r-- group::r-- group:dos:--- group:tres:--- class:r-- other:r--
When a new subdirectory is created, the parent directory's default ACL entries are added to the new subdirectory twice, first as its non-default ACL entries, and second as the subdirectory's default ACL entries. In this way, default ACLs propagate downward as trees of directories are created. If the file created in the previous example were instead a directory, its ACL would appear as follows:
# file: /a/dir # owner: creator_uid # group: creator_gid user::rwx user:beta:r-- user:gamma:r-- group::r-x group:dos:--- group:tres:--- class:r-x other:r-x default:user:beta:r-- default:user:gamma:r-- default:group:dos:--- default:group:tres:---
Access Check Algorithm
To determine the permission granted to an accessing process's effective user ID (EGID) and effective group ID (EGID), respectively, the following checks are made, in the following order:
Once access rights have been determined by one of the above checks, the subsequent checks in the list are not performed.
ACL Operations Supported
ACLs may be set, retrieved or counted, via the acl(2) system call. ACLs may be set or modified using the setacl(1) command, and may be retrieved using the getacl(1) command. The permissions granted to a particular user or group ID may be determined via the getaccess(1) command and the getaccess(2) system call. Files with certain ACL properties may be located using the -aclv option of find(1).
ACL Interaction with stat(2), chmod(2), and chown(2)
The <sys/aclv.h> header file defines the following constants to govern the numbers of entries per ACL:
The ACL structure struct acl is also defined, and includes the following members:
int a_type; /* type of entry */ uid_t a_id; /* group ID */ ushort a_perm; /* see <unistd.h> */
The <sys/aclv.h> header also defines the set of valid values for the a_type field, as well as the valid values for the cmd argument to the acl(2) system call.
The <sys/getaccess.h> header defines constants for use with getaccess(2).
Special parameter values for uid:
Special parameter values for ngroups:
ACLs cannot be used to restrict the superuser's access.
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 unable to handle ACLs on files with optional ACL entries (such as archive programs ar(1), cpio(1), ftio(1), tar(1), and dump(1M)), note the Access Control List information included on their respective reference pages to avoid loss of data.
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.