Access Control

Designing the access control model for the repository presented some challenges, because replication (Section 4.4) and other forms of remote access are sometimes needed between repositories that are in different realms; that is, repositories that are under separate administration, have different spaces of user names, and perhaps

% vattrib /vesta/west.vestasys.org/vesta/repos #owner [email protected] type package creation-time Thu Aug 22 17:41:35 PDT 1996 created-by [email protected] % vattrib /vesta/west.vestasys.org/vesta/repos/30 session-dir /vesta/west.vestasys.org/vesta/repos/checkout/30 old-version /vesta/west.vestasys.org/vesta/repos/29 message

Added code to gather usage statistics. content /vesta/west.vestasys.org/vesta/repos/checkout/30/12 checkin-time Tue Nov 4 14:10:22 PST 1997 checkin-by [email protected] #owner [email protected] % vattrib /vesta-work/mann/repos session-ver-arc 0 session-dir /vesta/west.vestasys.org/vesta/repos/checkout/31 old-version /vesta/west.vestasys.org/vesta/repos/30 new-version /vesta/west.vestasys.org/vesta/repos/31 checkout-time Wed Dec 3 09:55:12 PST 1997 checkout-by [email protected]

do not entirely trust one another. Thus we need a practical way of authenticating and access checking cross-realm requests. In addition, for repositories that are cooperating closely, we need it to be meaningful to replicate access control lists, so that each repository does not have to separately administer them. This section outlines how we have addressed these issues.

All access control lists and access checking in the repository are done in terms of global principal names, with the syntax user@realm orˆgroup@realm. The realm is an arbitrary name chosen by a system administrator, typically an Internet domain name that makes the realm’s user names valid email addresses. Group names are written with a leading caret only for clarity; there is not really any context in which both group names and user names can appear, so the caret is not needed to prevent ambiguity.

We have kept the repository’s access control lists close to the Unix style so that they can be manifested fairly accurately through the NFS interface. Each object has an owner ACL and a group ACL, plus a set of nine mode flags that indicate whether the owner, group, and others are granted read, write, and/or directory search access. Unlike the Unix model, the owner and group are sets of global names, not single local names; we have provided this feature mainly so that an object can be given different owners in different realms if desired. Therefore, when choosing which owner and group to manifest through the NFS interface, the repository searches first for one in the local realm. The repository maps between global principal names and the numeric user/group ids used through the NFS interface by examining the local operating system’s user and group registries (on Unix, /etc/passwdand

/etc/group) and building up a translation table.

Access control lists and mode flags are stored in mutable attributes named

#owner,#group, and#mode. Because not all objects have attributes, and to save space, we use a form of inheritance: if an object does not have a particu- lar access control attribute, it inherits the value from its parent directory. Hence, changing the access control on a directory can effectively change the access con- trol on other directories and files below it in the tree, a departure from conventional Unix semantics. The names of all access control attributes begin with an identify- ing character (“#”), and the replicator (Section 4.4) can be instructed not to copy them even if ordinary attributes are being copied.

Execute permission is treated specially. In Unix and NFS, a file’s execute bits encode two logically distinct items—whether the file is executable, and whether particular principals have permission to execute it. Within a given directory, some files may be executable and some not, so it is not appropriate for files to inherit execute permission from their parent directories. But a file stored in an immutable directory does not have a #mode attribute of its own, so we cannot set its per- missions individually. To work around this problem, the repository maintains an

executable flag for every file. When the Unix chmod function is invoked on a mutable file through the repository’s NFS interface, the file’s executable flag is set to the logical or of the three executable bits given; for immutable files, the flag is immutable too, andchmodhas no effect. We then use the executable flag and the read permission bits to determine the execute permission bits: if a file is executable, its three execute bits are a copy of its read bits; if not, they are all zero.

We also supply the Unix setuid and setgid flags. (The setuid flag tells the oper- ating system that if this file is executed as a program, the resulting process should be granted the privileges of the file’s owner; the setgid flag that it should be granted the privileges of the file’s group.) These flags are of no interest to Vesta itself, but the repository is careful to maintain them with the proper security; for example, a file’s setuid flag is automatically turned off if its owner is changed. The flags are encoded in an interesting way, designed to give the right security properties while considering the possibility of multiple and changing owners and groups. Both the

#setuidand#setgidattributes are sets of principal names. If the first value of

#ownerthat is in the local realm (the owner that will be manifested through the NFS interface) is also a value of#setuid, the setuid flag is set, otherwise not. Similarly, if the first value of#groupthat is in the local realm is also a value of

#setgid, the setgid bit is set, otherwise not.

Each incoming request to the repository must be authenticated as coming from some particular user. Several authentication methods are supported. The reposi- tory administrator fills in a table (similar in style to an NFS export table) that spec- ifies which user names to accept, from which hosts, using which authentication methods, and whether to grant normal or read-only access. Thus far we have im- plemented only two rather insecure authentication methods: the NFSAUTH UNIX

style, where the user provides his numeric Unix user id and is believed if he comes from a trusted host (needed to support most current NFS clients), and a similar style where the user supplies a global principal name and is believed if he comes from a host that is trusted for names from that realm. We have a design sketch for adding Kerberos authentication and hope to implement it in the future.

The repository recognizes three different administrative principals. The system administrator (Unix userroot) has blanket permission to perform any operation, except operations that could cause a violation of the replica agreement invariant (Section 4.4). For convenience, there is also a non-root Vesta administrator (typ- ically Unix uservadmin) that has the same permissions as root except for per- mission to modify the#setuidand#setgidflags; for the latter,vadmin is treated like an ordinary user. Thus, a designated non-root user can manage the Vesta repository, but cannot gain root access to other system resources or imper- sonate other users. There is also a special wizard user (typically Unix user name

violate the agreement invariant; this facility is provided only for emergency repairs and is not needed in normal operation.

Our general model for group access is that the user need only authenticate his user name; the repository determines what groups he is in. This model works well for intra-realm access, because the repository uses the local operating system’s facilities to determine the group membership of local users. A user accessing a remote repository, however, by default will not be recognized as a member of any groups, even groups from his own realm. To address this problem, we allow reposi- tory administrators to augment the group membership table with additional entries, but this is a bit labor-intensive. A useful future addition might be to allow group membership tables to be replicated.

As an additional feature, one user name or group name can be designated as an alias for another; this is useful when the same person has a login in two different realms or when two cooperating realms each have a group that is working on the same project.

We omit the details of what access permissions are required to perform most operations, which are generally obvious. Operations on attributes are controlled as follows. Changing an attribute whose name begins with #generally requires ownership access, except for a few special cases such as #owneritself (which requires administrative access), #setuid, and #setgid. Changing other at- tributes requires write access, while reading attributes is unrestricted.