acl(4)acl(4)NAMEacl - Access control list
DESCRIPTION
Note
The Tru64 UNIX ACLs are based on the POSIX P1003.6 Draft 13 standard.
Introduction
Traditionally, UNIX systems control a user's access to files and direc‐
tories using a method of discretionary access control (DAC) normally
referred to as the permission bits. By default, Tru64 UNIX systems are
run using this method of DAC for files and directories. This default
DAC, the permission bits, allows you to set discretionary access per‐
missions for the owning user, owning group, and “other”.
Access ACLs provide greater granularity of access permissions than the
default Tru64 UNIX DAC. Access ACLs provide discretionary access per‐
missions for the owning user, owning group, and “other”, and also pro‐
vide discretionary access permissions for individually specified users
and groups. An access ACL containing just the entries that correspond
to the permission bits should act identically to no ACL.
ACLs can be enabled and disabled dynamically and can be enabled sepa‐
rately from the other security options. This allows you to tailor your
system to use only the security options that you need, instead of hav‐
ing to setup all the security options. If ACLs are disabled on your
system, ACLs can still be set on files and directories, but the access
ACL will not be used for access permission checking and ACL inheritance
of any default ACLs will not take place for newly created files and
directories. See the Security guide for information on enabling and
disabling ACLs.
ACLs are extended file attributes stored in the file or directory's
property list. Currently ACLs are only supported for files and direc‐
tories on filesystems that support property lists. These are: UFS,
AdvFS, and NFS when distributed between Tru64 UNIX systems.
Types of ACLs and ACL Inheritance
An access ACL can be associated with a file or directory and controls
the access permissions to the file or directory.
There are two types of default ACLs, the default access ACL and the
default directory ACL. The default ACLs are only associated with
directories. They control what access ACLs and default ACLs are inher‐
ited by new files and subdirectories created within a directory that
has default ACL(s). When a default ACL is being inherited by a new
file or directory as an access ACL, the permission bits and their asso‐
ciated ACL entries are set to the intersection of the permission bits
from the default ACL and the mode parameter passed to the open(2),
creat(2), or mkdir(2) call, the umask is not used. This usually means
that when you're using a program or utility to copy a file, the file
gets the intersection of the permission bits from the source file and
the default ACL, NOT the umask. The other ACL entries in the new
access ACL are set from the entries in the default ACL, neither the
mode parameter or the umask affect these entries.
ACL Commands
The following commands display and change the contents of an ACL:
Changes an ACL on a file or directory. Displays an ACL on a file or
directory. GUI for editing and displaying ACLs
Contents of an ACL
A valid ACL must meet the following requirements: It must contain the 3
base entries that correspond to the permission bits. These are the
entries for “owning user”, “owning group”, and “other”. Entries can be
entered in any order with setacl. They need not correspond to the
order displayed by getacl. An ACL must be specified as either an
access, a default access, or a default directory ACL. The default ACLs
are associated with a directory only. Duplicate entries are not
allowed within a given ACL entry (tag) type. You cannot have two ACL
entries with the same user name or uid, for example.
ACL Text Format
The text format of an ACL consists of comma (,) or newline (<cr>) sepa‐
rated entries. Each entry has 3 fields, the entry (tag) type, the tag
qualifier, and the permissions. The permissions are represented simi‐
larly to the ls -l command. To restrict permissions, use a dash (-) in
place of any permission character.
There are 5 different types of entries: The owning user entry, tag
qualifier is empty. This corresponds to the owning user permission
bits. A user entry, tag qualifier is uid or user name. The owning
group entry, tag qualifier is empty. This corresponds to the owning
group permission bits. A group entry, tag qualifier is gid or group
name. The “other” entry, tag qualifier is empty. This corresponds to
the other permission bits.
The owning user entry, the owning group entry, and the other entry are
called the base entries and they are required. There may be zero or
more user and group entries up to a total of 62 user and group entries
in addition to the base entries. This limitation is based on a prop‐
erty list limitation in the AdvFS filesystem. The limit is config‐
urable on UFS and may be raised. See the Security guide for more
information.
Command Interaction
Existing commands interact with ACLs as follows: The chmod command
updates the contents of the ACL to match the new mode (permission bits)
being set on the object. The chown command changes the owning user.
This command does not change the ACL. The new owning user has the own‐
ing user permissions from the ACL. The owning user permissions are
checked first, so if there is a separate ACL entry for this user it is
ignored. See the Security guide for a complete description of access
checking with ACLs. The chgrp command changes the owning group. This
command does not change the ACL. The new owning group has the owning
group permissions from the ACL. When checking the ACL, the permissions
from all matching groups are ORed to get the final permissions. So, if
there is a separate ACL entry for this group it is granted in addition
to the owning group permissions. Currently ls does NOT give any indi‐
cation of the existence of ACLs. The cp command will not copy ACLs
unless the -p option is used.
Programming with ACLs
There is an ACL library, libpacl, which contains the functions neces‐
sary to manipulate ACLs from within a program. See the Security guide
and the individual man pages for descriptions of these functions.
An ACL has an internal and an external representation. The external
representation consists of text and is used to enter and display ACLs.
Library routines manipulate ACLs in working storage in an internal rep‐
resentation that is only indirectly accessible to the calling routine.
This internal representation can be interpreted with the <acl.h> header
file.
ACL Initialization
If any of the following system calls are used to create a file or a
directory, ACLs are enabled, and there are default ACL(s) on the parent
directory, ACL inheritance will take place. The creat() system call
The open() system call with the O_CREATE flag The mkdir() system call
When a file or directory is created, the default ACL(s) of its parent
directory are used in conjunction with the mode parameter passed to the
above system calls to determine the access ACL and permission bits of
the newly created file or directory. The process umask is not used if
default ACL inheritance takes place. If the parent directory doesn't
have default ACL(s), the process umask and system call mode parameter
are used to determine the permissions bits, as in traditional UNIX per‐
missions.
For a description of a process umask, see the umask(2) reference page.
Access Checks
The stat structure should not be used to determine accessability of a
file or directory. On local filesystems, read-only mounts and ACLs can
both modify the access that is allowed. On remote filesystems, in
addition to read- only mounts and ACLs, there may also be additional
controls that alter the permitted access, such as: ID mapping Mandatory
access control Additional authentication requirements
The access() call should always be used to do DAC access checking on a
file or directory.
See the Security guide for a description of the access decision process
for files and directories with access ACLs.
NFS Flatten Mode
The NFS flatten mode (nfs_flatten_mode) attribute in the “sec” subsys‐
tem controls the permission bits of a file or directory with an access
ACL as seen by an NFS V2 client. The sysconfigdb command should be
used to set this attribute in the /etc/sysconfigtab file.
NFS V2 clients make their own access decisions based on their interpre‐
tation of a file's permission bits. Based on this decision, they may
allow access to data cached on the client from a previous access by
another user. A file that is protected by an access ACL cannot reflect
the correct access for all users in the permission bits for the file.
It may be that access that would be granted by the permission bits is
actually denied explicitly by the access ACL. It may also be that
access that seems to be denied by the permission bits is, in fact,
granted explicitly by the access ACL. The nfs-flatten-mode parameter
can be used to modify the permission bits that exist on the server
before presentation to the client.
NFS V3 clients have, in essence, an “open” protocol request that they
use to defer the access decision to the server, and grants access only
when they have previously made an “open” request for the same user and
file.
Setting the nfs-flatten-mode parameter to the restrictive setting (1)
can cause some users to be denied access to files that they should
legitimately be granted access to. Setting the parameter to the per‐
missive setting (2) can cause some users to be granted access to files
that they should not be granted access to, but only for read access to
data in the client cache, since any request that is sent to the server
(and all write requests are supposed to be sent to the server) results
in an access decision on the server denying the request. Setting the
parameter to the unmodified setting (0) leaves the permission bits
unmodified, possibly resulting in both inadvertent denial and granting
of access, while accurately displaying the permission bits on the
client as they would be displayed on the server.
The allowable values are: The actual file permission bits are sent.
The owning group and other fields of the file permission bits are modi‐
fied such that only access that would be granted to everyone in the ACL
is granted by the permission bits. The owning group and other fields
of the file permission bits are modified such that access that is
granted to anyone in the ACL is granted by the permission bits.
The default value is 0.
SEE ALSO
Commands: setacl(1), chgrp(1), chmod(1), chown(1), getacl(1)
Functions: acl_add_perm(3), acl_clear_perm(3), acl_copy_entry(3),
acl_copy_ext(3), acl_copy_int(3), acl_create_entry(3),
acl_delete_def_fd(3), acl_delete_def_file(3), acl_delete_entry(3),
acl_delete_perm(3), acl_dup(3), acl_first_entry(3), acl_free(3),
acl_free_qualifier(3), acl_free_text(3), acl_from_text(3),
acl_get_entry(3), acl_get_fd(3), acl_get_file(3), acl_get_permset(3),
acl_get_qualifier(3), acl_get_tag_type(3), acl_init(3), acl_set_fd(3),
acl_set_file(3), acl_set_permset(3), acl_set_qualifier(3),
acl_set_tag_type(3), acl_size(3), acl_to_text(3), acl_valid(3)
Files: proplist(4)
Security
acl(4)