NAME
protection/acls - Details about Access Control Lists (ACLs)
DESCRIPTION
ACCESS CONTROL LIST
Every object in the system (whether directory or file) has an access
control list (ACL) that defines WHO may access that object, and in WHAT
ways. The ACL is made up of a series of entries that consist of two
elements: a subject identifier and a set of rights. Each entry gives one
subject the right to perform some operations (read, write, execute, etc)
on the object that the ACL protects. Each file is required to have an
associated person, group and organization. Each of these entries looks
like an ACL entry. In effect, there are required ACL entries and non-
required entries. The non-required entries are automatically arranged in
increasing order of specificity. That is, the ACLs for individuals
appear before the ACLs for all users. The required entries are placed
before corresponding non-required entries of the same type. Thus the
required person entry appears before all entries which have a person
specified, while the required group entry appears before all entries
which have a group specified and the required organization entry appears
before all entries which have an organization specified.
SUBJECT IDENTIFIERS
The subject identifier (SID) identifies those users to whom the specified
set of rights apply. The SID is in the pgo format, i.e.:
Person.Group.Organization
Barb.none.r_d
person, group, and organization specify names that are in the
associated network registry files. You may use the wildcard, % in any of
the "pgo" fields.
By convention, users with the group name backup may create backup copies
of files and directories on magnetic tape. Users with the group name
backup need read (r) access to files and directories. edacl issues a
warning when you change an ACL in a way that denies backup access.
However, edacl does execute the command. Ignore the warning only if the
object(s) does not require backup copies. If the object(s) does require
backup copies, edit the ACL again and grant group backup read access.
ACCESS RIGHTS
You may assign the following access rights to the types of objects
indicated:
Any object:
p protect rights; allow rights to be changed
Files:
w write rights; allows file to be written
r read rights; allows file to be read
x execute rights: allows file to be executed
k keep rights; prevents an object from being
deleted or from having its name changed
Directories:
w write rights; allows names to be added,
changed or deleted
r read rights; allows directory to be listed
s search rights; allows directory to be
searched for subordinate objects
x execute rights (synonym for search rights)
k keep rights; prevents an object from being
deleted or from having its name changed
SPECIFYING ACCESS RIGHTS
You may specify access rights individually or in groups. Table 1, below,
defines individual access rights. Table 2 defines the abbreviations you
may use to specify commonly assigned rights in groups.
Table 1.
Access Rights for Files and Directories
____________________________________________________________________
| | | | |
| Access Right |Abbreviation| Meaning for | Meaning for |
| | | Directories | Files |
|==============|============|===================|====================|
| | | |
| Protect | p | Change the object's ACL. |
|______________|____________|________________________________________|
| | | | |
| Read | r | List entries | Read file contents |
|______________|____________|___________________|____________________|
| | | | |
| Write | w | Add,change,delete| Write to the file |
| | | entries | |
|______________|____________|___________________|____________________|
| | | | |
| Execute | x | Allows directory | Execute object file|
| | | to be searched | |
| | | for subordinate | |
| | | objects | |
|______________|____________|___________________|____________________|
| | | | |
| Search | s | Same as execute | |
|______________|____________|___________________|____________________|
| | | | |
| Keep | k | Prevents deletion| Prevents deletion |
| | | or changing of | or changing |
| | | of name | of name |
|______________|____________|___________________|____________________|
NOTE: To delete a tree you need write rights to any object being
deleted. If objects are protected with Keep rights, you must
have Protect rights as well.
Table 2.
Abbreviations for Commonly Assigned Rights
____________________________________________________________________
| | | | |
| Term | Meaning | Directories | Files |
|==============|=======================|===============|=============|
| | | | |
| -owner | All rights | pwrx | pwrx |
|______________|_______________________|_______________|_____________|
| | | | |
| -user | All rights except | wrx | wrx |
| | ability to change ACL | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -read | File read access | not allowed | r |
|______________|_______________________|_______________|_____________|
| | | | |
| -exec | File read access | not allowed | rx |
| | Execute access to | | |
| | object files | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -ldir | List directories | rx | not allowed |
|______________|_______________________|_______________|_____________|
| | | | |
| -adir | List directories and | wrx | not allowed |
| | add entries | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -ignore | Ignore a required | | |
| | entry for rights | see text | see text |
| | checking | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -inh_rights| Inherit rights from | see text | not allowed |
| | current process | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -inh_pgo | Inherit pgo data | see text | not allowed |
| | from current process | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -inh_all | Inherit pgo data and | see text | not allowed |
| | rights from current | | |
| | process | | |
|______________|_______________________|_______________|_____________|
| | | | |
| -none | Grant no rights | None | None |
|______________|_______________________|_______________|_____________|
NOTES
edacl will not allow an operation that would restrict everyone from
changing an ACL. At least one user must have the right to change the
ACL(p).
Each object must have the required entries of Owner, Group and
Organization. However, it is sometimes useful to have these specified,
but not used for rights checking. This may be done by using the -ignore
abbreviation. -ignore is only valid for required entries.
Objects that are part of protected subsystems indicate this when their
ACLs are displayed.
ACLS AND DIRECTORIES
In addition to its own ACL, each directory contains two additional ACLs
(called "initial ACLs"): one for new files and another for new
subdirectories created within that directory. When you create a new file
or directory, or copy one to a new location in the file hierarchy, the
system assigns an ACL to it by copying the appropriate initial ACL stored
in the parent directory. When the newly created object is a directory,
the two initial ACLs from the parent are replicated in the new
subdirectory, unless you specifically indicate otherwise (see the cpt
(copy_tree) command). The various options on the edacl and acl commands
determine which of these several access control lists you are editing,
copying or displaying.
Initial ACLs may be either completely specified in the directory or may
inherit information from the process which is creating the object. Normal
Unix behavior is implemented by using inheritance from the process.
Either the sid information in a required entry or the rights information
in a required entry may be inherited (or both). The abbreviations
-inh_rights, -inh_pgo and -inh_all allow this inheritance to be
specified. These abbreviations are only valid for initial ACLs.
SEE ALSO
protection sids
for more information on SIDs.
protection rights
for more information on access rights.
acls
for more information on the commands that manipulate ACLs.
protected_subsystems
for more information on the commands that maintain protected subsystems.
protection protected_subsystems
for a detailed description of protected subsystems.