Access control lists (ACLs) may be associated with directories in Prospero, and with individual links within a directory. These access control lists specify how directory information is to be protected. They have nothing to do with the protection of the file to which a link refers. Table 1 lists the protection modes that may appear within an access control list entry.
Table 1: Protection modes in access control lists
When an entry appears in both columns, it means that the entry on the directory overrides the entry on a link. For example, a user with R access to the directory can read a link even if denied r access to the link. If a link permission is stored in a directory access control list, then that permission indicates the default protection associated with links in the directory that do not specify their own access control lists.
The administer permission allows the changing of the access control
list. View allows it to be viewed. List allows one to see a
directory entry using wildcard searches. Read is required to
determine the binding of a link (the file it references). If one is
allowed read, but not list, then one can only retrieve the link if its
exact name is specified. Modify allows one to change the binding of a
link, but it does not allow one to add or delete links. Insert allows
links to be added, and delete allows them to be deleted. The add and
remove rights are a restricted form of administer. They allow an
individual to add or remove a restricted set of rights. For example,
`` 
r'' allows one to grant read access to someone else without
also allowing one to grant modify access.
Negative rights may be specified by prepending a minus sign (-) to the rights field. The order of access control list entries is important. For negative rights to have an effect, they must precede any rights that authorize access by that individual. When new ACL entries are added, they are added at the front of the list, meaning that recent entries take precedence over older ones.
When access is checked for a link, three access control lists are checked. First, the ACL associated with the link itself is checked. If the link does not have its own ACL, then the default ACL associated with the directory is used. Next, the ACL associated with the directory is checked to see if it grants rights that override those in the link. Finally, if access has still not been granted, a special override ACL is checked. This is maintained by the system and should be used only in emergencies. Negative rights in one list does not override access granted in another.
There are several different ACL entry types. DEFAULT, SYSTEM, and DIRECTORY cause other access control lists to be
included. DEFAULT is the default ACL specified by the system on
which the Prospero server is running. SYSTEM is also specified
separately on each Prospero server. It usually grants additional
access to system administrators. DIRECTORY is the default
access control list associated with the directory containing a link.
It allows one to easily specify that the rights on a link are to be in
addition to the default rights specified in the directory. If no
rights are associated with these ACL entry types, then the rights
granted are based on those in the DEFAULT, SYSTEM, or DIRECTORY access control lists themselves. If rights are specified
for such entries, then the rights are the minimum of those specified,
and those in the included ACL. The ACLs for new files and directories
allow access to DEFAULT and SYSTEM as defined in those
lists. Users have the option of removing such access
.
The ANY, AUTHENT, ASRTHOST, and TRSTHOST ACL types grant rights to the specified individuals according to the accompanying permission list. ANY matches any user. AUTHENT specifies an authentication method, and the name of the authorized individual as returned by that method. At present, this entry type is not supported. The ASRTHOST method specifies a list of authorized principals in the form user@internet-address. If no Internet address is specified (and no atsign), then the user is matched regardless of the requesting host. Octets of the Internet address can be wildcarded, or replaced with a `%'. A wildcard matches any number, and a `%' matches the number corresponding to the local host. For example, ``bcn@%.%.%.*'' matches the user ``bcn'' on the local subnet. The user may be specified as *, meaning to match any user at that internet-address.
The ASRTHOST type accepts the username asserted by the client.
It is not possible to verify that the user has not modified the
software to claim someone else's identity. The Internet address can
generally be considered accurate, though it too can be spoofed by a
knowledgeable and determined attacker. The TRSTHOST type is
identical to the ASRTHOST type, but is accepted only when the
request originates from a privileged port on the requesting system.
Although this method might be used to provide security similar to that
for the Berkeley R commands, it is not recommended that you install
Prospero binaries setuid root until the sources have undergone careful
scrutiny for possible security holes.
The discussion of ACLs in this section is not inaccurate, but it does not yet reflect the new object and container ACLs that are new with Prospero version Alpha.5.2. Preliminary documentation on the new rights we have developed for object ACLs is available in the text file doc/working-notes/new-acl-types in the Prospero distribution. This text file will be merged into this manual shortly.
NAMED ACLs have been added. They are stored in the directory F_SECURITY/named. They are used to specify a common ACL on some server which a number of objects may share. They are referred to in other ACLs by using the LGROUP (local group) ACL type. Each named ACL must be created and modified by the server's maintainer; this is currently done by manually modifying the file F_SECURITY/named/acl-name on the Prospero server.
The OVERRIDE, SYSTEM, DEFAULT, and MAINTENANCE ACLs may also be modified in this way, without needing to recompile the Prospero server - for those four special ACLs, the corresponding file is F_SECURITY/ named/OVERRIDE.config, F_SECURITY/named/SYSTEM.config, etc. These files, if present, are read into the server at startup time..
The ppw command, which allows one to set and manipulate a password-based authentication mechanism that is stronger than the ASRTHOST type also needs to be documented here, as do the Kerberos version 5 authentication facilities which are present in this release.
The system administrator's pw_edit command also must be documented here.