aclv(5) aclv(5)
NAME [Toc] [Back]
aclv - introduction to JFS access control lists (ACLs)
DESCRIPTION [Toc] [Back]
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 non-privileged 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 inter-process communication (IPC) objects.
This manual page describes ACLs as implemented on JFS file systems
only. See acl(5) for a description of ACLs in HFS file systems.
Definitions [Toc] [Back]
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 ``A specific type of interaction between a subject and
an object that results in the flow of information from
one to the other.'' Subjects include ``persons,
processes, or devices that cause information to flow
among objects or change the system state.'' Objects
include files (ordinary files, directories, special
files, FIFOs, etc.) and inter-process communication
(IPC) features (shared memory, message queues,
semaphores, sockets).
access control list (ACL)
An access control list is a set of (user|group, mode)
entries associated with a file that specify permissions
for all possible user-IDs and/or group-IDs.
access control list (ACL) entry
An entry in an ACL that specifies access rights for a
Hewlett-Packard Company - 1 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
file's owner, owning group, group class, additional
user, additional group, or all others.
change permission
The right to alter DAC information (permission bits or
ACL entries). Change permission is granted to object
(file) owners and to privileged users.
discretionary access control (DAC)
``A means of restricting access to objects based on the
identity of subjects and/or groups to which they
belong. The controls are discretionary in the sense
that a subject with a certain access permission is
capable of passing that permission (perhaps indirectly)
to any other subject.''
mode Three bits in each ACL entry which represent read,
write, and execute/search permissions. These bits may
exist in addition to the 16 mode bits associated with
every file in the file system (see glossary(9)).
privilege The ability to ignore access restrictions and change
restrictions imposed by security policy and implemented
in an access control mechanism. In HP-UX, superusers
and members of certain groups (see privgrp(4)) are the
only privileged users.
restrictive versus permissive
An individual ACL entry is considered restrictive or
permissive, depending on context. Restrictive entries
deny a user and/or group access that would otherwise be
granted by less-specific base or optional ACL entries
(see below). Permissive entries grant a user and/or
group access that would otherwise be denied by lessspecific
base or optional ACL entries.
Access Control List Entries [Toc] [Back]
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 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
The file owner is user james.
The file's group is admin.
Hewlett-Packard Company - 2 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
The name of the file is datafile.
The file owner permissions are rwx.
The file group permissions are r-x.
The file other permissions are r--.
In an ACL, user and group IDs can be represented by names or numbers,
found in /etc/passwd.
ACL Notation [Toc] [Back]
Supported commands that manage JFS ACLs recognize the following
symbolic representation:
[d[efault]:]u[ser]:[uid]:perm
[d[efault]:]g[roup]:[gid]:perm
[d[efault]:]c[lass]:perm
[d[efault]:]o[ther]:perm
An ACL entry prefixed with d: or default:, can only occur 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 [Toc] [Back]
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.
u::perm Base ACL entry for the file's owner
g::perm Base ACL entry for the file's group
c::perm Base ACL entry for the file's group class
o::perm Base ACL entry for others
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.
Hewlett-Packard Company - 3 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
Optional ACL entries [Toc] [Back]
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:
u:mary:rwx Grant read, write, and execute access to user
mary.
user:george:--- Deny any access to user george.
g:writers:rw- Grant read and write access to members of
group writers.
Class Entries [Toc] [Back]
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
groupclass 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.
ACL Uniqueness [Toc] [Back]
Entries are unique in each ACL. There can only be one of each type of
base entry, and one entry for any given user or group ID. Likewise,
there can only be one of each type of default base entry, and one
default entry for any given user or group ID.
ACL Inheritance [Toc] [Back]
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.
Hewlett-Packard Company - 4 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
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 /a'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 nondefault
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--
Hewlett-Packard Company - 5 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
default:group:dos:---
default:group:tres:---
Access Check Algorithm [Toc] [Back]
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:
If the EUID of the process is the same as the owner of the file,
grant the permissions specified in the user:: entry.
If the EUID matches the UID specified in one of the additional
user:uid: entries, grant the permissions specified in that entry,
bitwise-ANDed with the permissions specified in the class entry.
If the EGID of the process is the same as the owning group of the
file, grant the permissions specified in the group:: entry.
If the EGID matches the UID specified in one of the additional
group:gid: entries, grant the permissions specified in that
entry, bitwise-ANDed with the permissions specified in the class
entry.
Otherwise, grant the permissions specified in the other entry.
Once access rights have been determined by one of the above checks,
the subsequent checks in the list are not performed.
ACL Operations Supported [Toc] [Back]
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)
stat The st_mode field summarizes the caller's access rights to the
file. It differs from file permission bits only if the file
has one or more optional entries applicable to the caller.
The st_basemode field provides the file's actual permission
bits. The st_aclv field indicates the presence of optional
ACL entries in the file's ACL.
The st_mode field contains a user-dependent summary, so that
programs ignorant of ACLs that use stat(2) and chmod(2) are
more likely to produce expected results, and so that stat(2)
provides reasonable information about remote files over NFS.
The st_basemode and st_aclv fields are useful only for local
files.
Hewlett-Packard Company - 6 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
chmod Setting the group permission bits via chmod(2) system call
affects the file's class entry, which would in turn affect the
permissions granted by additional user:uid: and group:gid:
entries. In particular, using chmod(2) to set a file's
permission bits to all zeroes removes all access to the file,
regardless of permissions granted by any additional user:uid:
or group:gid: entries.
chown When a file's owner or owning group are changed via chown(2)
to a UID or GID which have existing user:uid: or group:gid:
entries, those entries are not removed from the ACL, but they
are rendered moot, because the user:: or group:: entries take
precedence.
HEADERS [Toc] [Back]
Header <sys/acl.h>
The <sys/aclv.h> header file defines the following constants to govern
the numbers of entries per ACL:
NACLVENTRIES maximum number of entries per ACL,
including base entries
NACLBASE number of base entries
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.
Header <sys/getaccess.h>
The <sys/getaccess.h> header defines constants for use with
getaccess(2).
Special parameter values for uid:
UID_EUID use effective user ID
UID_RUID use real user ID
UID_SUID use saved user ID
Special parameter values for ngroups:
NGROUPS_EGID process's effective gid
NGROUPS_RGID process's real gid
NGROUPS_SGID process's saved gid
NGROUPS_SUPP process's supplementary groups only
NGROUPS_EGID_SUPP process's eff gid plus supp groups
Hewlett-Packard Company - 7 - HP-UX 11i Version 2: August 2003
aclv(5) aclv(5)
NGROUPS_RGID_SUPP process's real gid plus supp groups
NGROUPS_SGID_SUPP process's saved gid plus supp groups
WARNINGS [Toc] [Back]
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 (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.
DEPENDENCIES [Toc] [Back]
NFS 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.
AUTHOR [Toc] [Back]
The access control list design described here was developed by AT&T.
FILES [Toc] [Back]
<sys/aclv.h> Header file that supports acl(2).
/etc/passwd Defines user names and user and group ID values.
/etc/group Defines group names.
SEE ALSO [Toc] [Back]
chmod(1), cp(1), find(1), getaccess(1), getacl(1), ln(1), ls(1),
mv(1), rm(1), setacl(1), fbackup(1M), frecover(1M), fsck(1M), fsdb(1M)
access(2), acl(2), chmod(2), chown(2), creat(2), getaccess(2),
mknod(2), open(2), stat(2), aclsort(3), cpacl(3), group(4), passwd(4),
privgrp(4), acl(5).
Hewlett-Packard Company - 8 - HP-UX 11i Version 2: August 2003 [ Back ] |