acl - Access control list
The Tru64 UNIX ACLs are based on the POSIX P1003.6 Draft 13 stan-
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 permissions 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 permis-
sions for the owning user, owning group, and "other", and also provide dis-
cretionary 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 separately
from the other security options. This allows you to tailor your system to
use only the security options that you need, instead of having 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 pro-
perty list. Currently ACLs are only supported for files and directories 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 inherited 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 associated 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.
The following commands display and change the contents of an ACL:
setacl Changes an ACL on a file or directory.
getacl Displays an ACL on a file or directory.
dxsetacl 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
+ 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 direc-
+ 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
ACL text format:
The text format of an ACL consists of comma (,) or newline (<cr>) separated
entries. Each entry has 3 fields, the entry (tag) type, the tag qualifier,
and the permissions. The permissions are represented similarly to the ls
-l command. To restrict permissions, use a dash (-) in place of any per-
There are 5 different types of entries:
user::rwx 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 addi-
tion to the base entries. This limitation is based on a property list lim-
itation in the AdvFS filesystem. The limit is configurable on UFS and may
be raised. See the Security guide for more information.
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 owning 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
+ 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 match-
ing 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 indication of the existence of ACLs.
+ The cp command will not copy ACLs unless the -p flag is used.
Programming with ACLs
There is an ACL library, libpacl, which contains the functions necessary to
manipulate ACLs from within a program. See Chapter 22 of 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
representation that is only indirectly accessible to the calling routine.
This internal representation can be interpreted with the acl.h header file.
If any of the following system calls are used to create a file or a direc-
tory, ACLs are enabled, and there are default ACL(s) on the parent direc-
tory, 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 deter-
mine the permissions bits, as in traditional UNIX permissions.
For a description of a process umask, see the umask(2) reference page.
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
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" subsystem
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 interpreta-
tion 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 permissive 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 set-
ting (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:
0 - unmodified
The actual file permission bits are sent.
1 - restrictive
The owning group and other fields of the file permission bits are
modified such that only access that would be granted to everyone in
the ACL is granted by the permission bits.
2 - permissive
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.
Commands: setacl(1), chgrp(1), chmod(1), chown(1), getacl(1)