acl - Access control list
Note
The Tru64 UNIX ACLs are based on the POSIX P1003.6 Draft
13 standard.
Introduction [Toc] [Back]
Traditionally, UNIX systems control a user's access to
files and directories 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 permissions for the owning user, owning
group, and "other", and also provide 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 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 property 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 [Toc] [Back]
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.
ACL Commands [Toc] [Back]
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 [Toc] [Back]
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 [Toc] [Back]
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 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 property list limitation in the AdvFS filesystem. The
limit is configurable on UFS and may be raised. See the
Security guide for more information.
Command Interaction [Toc] [Back]
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 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 indication
of the existence of ACLs. The cp command will not
copy ACLs unless the -p option is used.
Programming with ACLs [Toc] [Back]
There is an ACL library, libpacl, which contains the functions
necessary 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 representation that is
only indirectly accessible to the calling routine. This
internal representation can be interpreted with the
<acl.h> header file.
ACL Initialization [Toc] [Back]
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 permissions.
For a description of a process umask, see the umask(2)
reference page.
Access Checks [Toc] [Back]
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 readonly
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 [Toc] [Back]
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 interpretation 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 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 modified 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.
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)
[ Back ] |
