 |
Index for
Section 4 |
|
 |
Alphabetical
listing for A |
|
 |
Bottom of
page |
|
acl(4)
NAME
acl - 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
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
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
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
"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>) 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:
user::rwx
The owning user entry, tag qualifier is empty. This corresponds to the
owning user permission bits.
user:userid:rwx
A user entry, tag qualifier is uid or user name.
group::rwx
The owning group entry, tag qualifier is empty. This corresponds to the
owning group permission bits.
group:groupid:rwx
A group entry, tag qualifier is gid or group name.
other::rwx
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
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
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
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
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" 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:
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.
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
|
Index for
Section 4 |
|
|
Alphabetical
listing for A |
|
 |
Top of
page |
|