IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.5, MAY 1986
`
`635
`
`Privilege Transfer and Revocation
`in a Port-Based System
`
`KRITHIVASAN RAMAMRITHAM, DAVID STEMPLE, MEMBER,
`STEPHEN VINTER
`
`IEEE, DAVID A. BRIGGS, AND
`
`Abstract-Gutenberg is a port-based operating system being de(cid:173)
`signed to study protection issues in distributed systems. In the Guten(cid:173)
`berg system, all shared resources are viewed as protected objects and
`hence can be accessed only via specific operations defined on them.
`Processes communicate and access objects through the use of ports.
`Each port is associated with an abstract data type operation and can
`be created by a process only if the process has the capability to execute
`the operation on the type. Thus, a port represents the privilege of the
`port's client process to request a service (an abstract data type opera(cid:173)
`tion) provided by the port's server process (the type's manager). Ca(cid:173)
`pabilities to create ports for requesting operations are contained in a
`capability directory, which is navigated by processes to gain these ca(cid:173)
`pabilities.
`Privilege transfer is a means of providing servers access to the re(cid:173)
`sources they need to perform their services. In Gutenberg, privilege
`transfer is accomplished by allowing access to subdirectories of the ca(cid:173)
`pability directory and by passing capabilities, including port access ca(cid:173)
`pabilities, to processes via ports. It should be possible to revoke trans(cid:173)
`ferred privileges when breaches of trust are detected or suspected, when
`a period of time has passed beyond which the distributor of a privilege
`does not want the privilege shared, or when an error has been detected.
`Transfer and revocation of privileges in Gutenberg is the subject of
`this paper. In particular, we describe the types of privileges in Guten(cid:173)
`berg, discuss the mechanisms provided for the transfer and revocation
`of different types of privileges, and sketch the means for handling ex(cid:173)
`ceptions during privilege transfer.
`
`Index Terms-Interprocess communication, operating systems,
`privilege transfer, protection, revocation.
`
`I.
`
`INTRODUCTION
`
`L ARGE software systems are best organized by break(cid:173)
`
`ing them down into modules which communicate in
`limited ways and whose privileges are restricted to those
`needed to perform the modules' designated services. One
`way of restricting the privileges of an executing module
`is for the initiator of the module to explicitly supply the
`privileges at the time of module initiation. Another way
`is for the module to receive privileges during execution
`along communication channels connecting it to its com(cid:173)
`munication partners. Other methods include the granting
`of privileges, to the module, based on the user (an entity
`
`Manuscript received October 31, 1983; revised September 28, 1984.
`This work was supported in part by the National Science Foundation under
`Grants MCS 82-02586, DCR-8403097, and DCR-8500332.
`K. Ramamritham and D. Stemple are with the Department of Computer
`and Information Science, University of Massachusetts, Amherst, MA
`01003.
`D. A. Briggs is with the Department of Mathematics and Computer Sci(cid:173)
`ence, University of Southern Maine, Portland, ME 04104.
`S. Vinter is with BBN Laboratories, Cambridge, MA 02238.
`IEEE Log Number 8607939.
`
`external to the system) on whose behalf the module is
`being initiated. In this paper, we are concerned mainly
`with the first two methods of explicit privilege transfer,
`i.e., during module initiation and as a part of interprocess
`communication.
`In object-oriented systems, resources are structured as
`objects which can be accessed only via the operations de(cid:173)
`fined on them. In such systems, the privileges of a process
`specify the objects that it can access and the operations
`that it is allowed to perform on them. A protection scheme
`permits a module to perform operations on a specified ob(cid:173)
`ject only if the module has the appropriate privilege. Ob(cid:173)
`ject-oriented privilege transfer refers to mechanisms in
`which privileges transferred are expressed in terms of op(cid:173)
`erations on specific objects. Such mechanisms are pro(cid:173)
`vided in several systems [1], [5], [16].
`In this paper, we deal with the transfer of privileges in
`the Gutenberg operating system [8], [9], [11], which uses
`an object-oriented protection scheme to control the inter(cid:173)
`action of modules represented by processes. Gutenberg is
`also a port-based system in that all communication be(cid:173)
`tween processes, including process initiation, is accom(cid:173)
`plished using ports.
`Although not always provided by programming lan(cid:173)
`guages or operating systems, the ability to revoke trans(cid:173)
`ferred privileges is often useful. Revocation is appropri(cid:173)
`ate, for instance, when a breach of trust has been detected
`or is suspected, where a period of time has elapsed be(cid:173)
`yond which it is not desired to share the transferred priv(cid:173)
`ilege, and where recovery from an error requires the re(cid:173)
`vocation of a transferred privilege. Hence, Gutenberg
`provides for the revocation of transferred privileges. One
`of the assumptions we have made in designing the revo(cid:173)
`cation mechanism is that the occasions for revocation are
`exceptional and infrequent as opposed to the frequent need
`for transferring privileges; thus, mechanisms designed for
`revocation should not unduly complicate nor slow down
`the transfer mechanism in situations where it is known
`that the transferred privileges will not be revoked.
`Gligor has designed a revocation scheme in which revo(cid:173)
`cation mechanisms form a subsystem above the (verified)
`protection kernel [4]. The premise underlying such a de(cid:173)
`sign is that unauthorized retention of access privileges re(cid:173)
`sulting from incorrect behavior of the revocation subsys(cid:173)
`tem will not violate protection requirements; hence, unlike
`the protection kernel which needs to be verified, the re-
`
`0098-5589/86/0500-0635$01.00 © 1986 IEEE
`
`

`

`IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.5, MAY 1986
`
`635
`
`Privilege Transfer and Revocation
`in a Port-Based System
`
`KRITHIVASAN RAMAMRITHAM, DAVID STEMPLE, MEMBER,
`STEPHEN VINTER
`
`IEEE, DAVID A. BRIGGS, AND
`
`Abstract-Gutenberg is a port-based operating system being de(cid:173)
`signed to study protection issues in distributed systems. In the Guten(cid:173)
`berg system, all shared resources are viewed as protected objects and
`hence can be accessed only via specific operations defined on them.
`Processes communicate and access objects through the use of ports.
`Each port is associated with an abstract data type operation and can
`be created by a process only if the process has the capability to execute
`the operation on the type. Thus, a port represents the privilege of the
`port's client process to request a service (an abstract data type opera(cid:173)
`tion) provided by the port's server process (the type's manager). Ca(cid:173)
`pabilities to create ports for requesting operations are contained in a
`capability directory, which is navigated by processes to gain these ca(cid:173)
`pabilities.
`Privilege transfer is a means of providing servers access to the re(cid:173)
`sources they need to perform their services. In Gutenberg, privilege
`transfer is accomplished by allowing access to subdirectories of the ca(cid:173)
`pability directory and by passing capabilities, including port access ca(cid:173)
`pabilities, to processes via ports. It should be possible to revoke trans(cid:173)
`ferred privileges when breaches of trust are detected or suspected, when
`a period of time has passed beyond which the distributor of a privilege
`does not want the privilege shared, or when an error has been detected.
`Transfer and revocation of privileges in Gutenberg is the subject of
`this paper. In particular, we describe the types of privileges in Guten(cid:173)
`berg, discuss the mechanisms provided for the transfer and revocation
`of different types of privileges, and sketch the means for handling ex(cid:173)
`ceptions during privilege transfer.
`
`Index Terms-Interprocess communication, operating systems,
`privilege transfer, protection, revocation.
`
`I.
`
`INTRODUCTION
`
`L ARGE software systems are best organized by break(cid:173)
`
`ing them down into modules which communicate in
`limited ways and whose privileges are restricted to those
`needed to perform the modules' designated services. One
`way of restricting the privileges of an executing module
`is for the initiator of the module to explicitly supply the
`privileges at the time of module initiation. Another way
`is for the module to receive privileges during execution
`along communication channels connecting it to its com(cid:173)
`munication partners. Other methods include the granting
`of privileges, to the module, based on the user (an entity
`
`Manuscript received October 31, 1983; revised September 28, 1984.
`This work was supported in part by the National Science Foundation under
`Grants MCS 82-02586, DCR-8403097, and DCR-8500332.
`K. Ramamritham and D. Stemple are with the Department of Computer
`and Information Science, University of Massachusetts, Amherst, MA
`01003.
`D. A. Briggs is with the Department of Mathematics and Computer Sci(cid:173)
`ence, University of Southern Maine, Portland, ME 04104.
`S. Vinter is with BBN Laboratories, Cambridge, MA 02238.
`IEEE Log Number 8607939.
`
`external to the system) on whose behalf the module is
`being initiated. In this paper, we are concerned mainly
`with the first two methods of explicit privilege transfer,
`i.e., during module initiation and as a part of interprocess
`communication.
`In object-oriented systems, resources are structured as
`objects which can be accessed only via the operations de(cid:173)
`fined on them. In such systems, the privileges of a process
`specify the objects that it can access and the operations
`that it is allowed to perform on them. A protection scheme
`permits a module to perform operations on a specified ob(cid:173)
`ject only if the module has the appropriate privilege. Ob(cid:173)
`ject-oriented privilege transfer refers to mechanisms in
`which privileges transferred are expressed in terms of op(cid:173)
`erations on specific objects. Such mechanisms are pro(cid:173)
`vided in several systems [1], [5], [16].
`In this paper, we deal with the transfer of privileges in
`the Gutenberg operating system [8], [9], [11], which uses
`an object-oriented protection scheme to control the inter(cid:173)
`action of modules represented by processes. Gutenberg is
`also a port-based system in that all communication be(cid:173)
`tween processes, including process initiation, is accom(cid:173)
`plished using ports.
`Although not always provided by programming lan(cid:173)
`guages or operating systems, the ability to revoke trans(cid:173)
`ferred privileges is often useful. Revocation is appropri(cid:173)
`ate, for instance, when a breach of trust has been detected
`or is suspected, where a period of time has elapsed be(cid:173)
`yond which it is not desired to share the transferred priv(cid:173)
`ilege, and where recovery from an error requires the re(cid:173)
`vocation of a transferred privilege. Hence, Gutenberg
`provides for the revocation of transferred privileges. One
`of the assumptions we have made in designing the revo(cid:173)
`cation mechanism is that the occasions for revocation are
`exceptional and infrequent as opposed to the frequent need
`for transferring privileges; thus, mechanisms designed for
`revocation should not unduly complicate nor slow down
`the transfer mechanism in situations where it is known
`that the transferred privileges will not be revoked.
`Gligor has designed a revocation scheme in which revo(cid:173)
`cation mechanisms form a subsystem above the (verified)
`protection kernel [4]. The premise underlying such a de(cid:173)
`sign is that unauthorized retention of access privileges re(cid:173)
`sulting from incorrect behavior of the revocation subsys(cid:173)
`tem will not violate protection requirements; hence, unlike
`the protection kernel which needs to be verified, the re-
`
`0098-5589/86/0500-0635$01.00 © 1986 IEEE
`
`

`

`636
`
`IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.5, MAY 1986
`
`vocation subsystem need not be verified. We believe that
`retention of revoked privileges is equivalent to the pos(cid:173)
`session of unauthorized privileges and is tantamount to a
`protection violation. Retention of revoked privilege is not
`to be allowed or relegated to any mechanism outside the
`protection kernel. Thus, the Gutenberg kernel includes the
`revocation mechanisms, and they will be verified along
`with the privilege transfer mechanisms.
`Systems designed with the goal of protecting resources
`incur the overheads of checking the privileges of pro(cid:173)
`cesses when they attempt to access resources. In a dy(cid:173)
`namic system, i.e., one which allows transfer of privi(cid:173)
`leges during the execution of a process and not just at its
`initiation (e.g., see [12]), the privileges of a process vary
`depending on what privileges are transferred to it. Hence
`the system has to keep track of transferred privileges and
`update the privileges of the processes involved in trans(cid:173)
`fers. If, in addition, a system allows privileges to be re(cid:173)
`voked, further overheads will be incurred, since in this
`case the system must keep track of how a receiving pro(cid:173)
`cess uses the transferred privileges in order to prevent their
`use after revocation.
`Since there are considerable overheads involved in
`privilege transfer and revocation, it is imperative that pro(cid:173)
`tection systems be designed so that these overheads are
`minimal. One way of achieving this goal is to keep the
`kernel as simple as possible while providing sufficient
`flexibility in the protection facilities. Thus, compromises
`must be made. The set of kernel primitives, the privilege
`transfer and revocation mechanisms, and the classifica(cid:173)
`tion of privileges in Gutenberg are the results of the compro(cid:173)
`mises made in meeting the conflicting requirements of
`simplicity, flexibility, and usefulness. In subsequent sec(cid:173)
`tions, as we describe the kernel primitives and the protec(cid:173)
`tion scheme, we present the design choices and the mo(cid:173)
`tivation for our decisions.
`Although Gutenberg has been designed to study issues
`in distributed systems, transfer and revocation of privi(cid:173)
`leges are discussed in this paper only in the context of a
`centralized system. Research dealing with the issues of
`distribution is currently in progress and will be reported
`in a future paper.
`The remainder of the paper is organized as follows. The
`next section presents the main features of the Gutenberg
`system. It is followed by the details of privilege transfer
`using the Gutenberg primitives. Revocation of privileges
`is then discussed and its aspects classified. We then pre(cid:173)
`sent the Gutenberg means of revoking privileges. Follow(cid:173)
`ing this we discuss the disruptions possible during privi(cid:173)
`lege transfer and the mechanisms involved in assuring
`reliable behavior in the presence of disruptions. We end
`with a summary section.
`
`II. THE GUTENBERG SYSTEM
`Gutenberg is a port-based, object-oriented kernel being
`designed to study protection issues in distributed systems.
`In the Gutenberg system, all shared resources are viewed
`as protected objects and hence have specific operations
`
`defined on them. Processes communicate and access shar(cid:173)
`able objects through the use of ports. The basic principle
`of protection in Gutenberg is: a port connecting a process
`to the manager of an object exists only if the process has
`the privilege to access the object with a specific opera(cid:173)
`tion.
`Capability-based operating systems, e.g., Plessey 250
`[3], CAL [6], Hydra [2], and iMAX [5], provide for the
`protection of objects through the use of transferable, un(cid:173)
`forgeable capabilities for accessing objects. Capabilities
`are means for providing the control implicit in the abstract
`data type paradigm, i.e., the limiting of object access to
`a set of operations defined by the type. To date, however,
`capabilities have been expensive to implement either in
`software or hardware, and need further development be(cid:173)
`fore they can demonstrate their cost-effectiveness. The
`main problem seems to be their use for controlling ac(cid:173)
`cesses both to entities external to a module and to local
`data and procedures. The Gutenberg system represents an
`attempt to avoid this problem by using a capability scheme
`for controlling process interactions, but not for local pro(cid:173)
`cedure calls and other access within a process. This ap(cid:173)
`proach we have called a nonuniform object model ofpro(cid:173)
`tection: data local to a process are not protected by the
`kernel; resources shared by multiple processes are struc(cid:173)
`tured as objects and are protected by the kernel. This ap(cid:173)
`proach, along with the use of ports for all access to user(cid:173)
`defined,
`shared objects, distinguishes Gutenberg from
`other capability-based systems.
`Another difference between Gutenberg and other pro(cid:173)
`posed protection systems [16], [6], [7] arises from the way
`privileges persist in the system. In other systems, the pos(cid:173)
`sessor of a privilege is allowed to store the privilege in
`long-lived user-managed objects, such as files or direc(cid:173)
`tories. In Gutenberg, all privileges which persist indepen(cid:173)
`dently of the existence of processes are maintained in a
`system capability directory managed solely by the kernel.
`Other salient features of Gutenberg are use of the client(cid:173)
`server model
`in port communication and a strict adher(cid:173)
`ence to functional addressing in the establishment of ports
`[14]. The latter feature is characterized by the creation of
`ports for the purpose of requesting specified functions
`rather than to connect to specified processes: a port cre(cid:173)
`ated by one process is connected to a second process based
`on a specified function (a service or abstract data type op(cid:173)
`eration) and a cooperation class with which the service is
`to be associated. The concept and implementation of co(cid:173)
`operation class in Gutenberg is itself a unique feature and
`is treated in a separate paper [13].
`
`A. Kernel Objects and Primitives
`Gutenberg's nonuniform object model of protection is
`based on a few basic kernel objects and the use of these
`system objects for expressing the protection requirements
`of user-defined objects. To help distinguish between ker(cid:173)
`nel and user-defined objects we say that processes execute
`kernel primitives to manipulate kernel objects and request
`operations to manipulate remote user-defined objects, i.e.,
`
`

`

`RAMAMRITHAM et al.: PRIVILEGE TRANSFER IN A PORT-BASED SYSTEM
`
`637
`
`objects managed by other processes. The objects recog(cid:173)
`nized by the kernel are:
`• processes: the subjects which share access to objects;
`• ports: used to request access to shared objects;
`• the capability directory: a unified structure, orga(cid:173)
`nized similar to a Unix file directory [10], containing ca(cid:173)
`pabilities. It is a stable structure in that its existence does
`not depend on the existence of any process. It contains
`four kinds of stable capabilities:
`-soperation capability:
`represents the privilege to
`create a port for use in requesting a named operation on
`~ given user-defined object type; it is linked to a manager
`definition capability corresponding to the object type.
`-manager definition capability: represents the priv(cid:173)
`ilege to create new operation capabilities linked to this
`capability, and' to redefine operations'
`implementations;
`it points to the executable image of the process that man(cid:173)
`ages the object on which the operation is defined; corre(cid:173)
`sponds to a type capability in Hydra.
`-cooperation class capability: represents the privi(cid:173)
`lege to participate in a cooperative activity identified by
`a unique identifier, the cooperation class identifier. An
`example of a cooperative activity is communicating with
`the process that manages a shared instance of an object
`type.
`-subdirectory capability: represents the privilege to
`in a re(cid:173)
`obtain a group of capabilities, a subdirectory,
`stricted way. The capabilities contained in a subdirectory
`are said to be registered in that subdirectory.
`• transient capabilities: these capabilities are port ca(cid:173)
`pabilities and copies of stable capabilities from the capa(cid:173)
`bility directory; a process's transient capabilities are
`stored in its capability list (c-list), and only exist for the
`duration of the process's existence.
`A capability in other systems consists of: an object
`identifier, the object's type, and the subset of the opera(cid:173)
`tions defined by the type that are permitted by the capa(cid:173)
`bility. Since object types can be user-defined, the defini(cid:173)
`tion of operations in some capabilities are determined by
`the user.
`Capabilities in Gutenberg are somewhat different, con(cid:173)
`sisting of: a specific kernel primitive, a list of kernel-ob(cid:173)
`ject identifiers constituting legal parameters for the prim(cid:173)
`itive, and a list of primitives that can be used to manipulate
`the capability itself (called capcaps , for capabilities on a
`capability). Capcaps include the privilege to transfer, reg(cid:173)
`ister (make stable), hold (make transient), and modify the
`capability. A capability permits a process with that ca(cid:173)
`pability to exercise the kernel primitive in the capability.
`For example, with an operation capability a process can
`perform the kernel primitive CREATEPORT with the
`name
`of
`the
`operation
`being
`a
`parameter
`to
`CREATEPORT.
`The purpose of the capability directory is to restrict the
`acquisition of capabilities by processes in a consistent and
`orderly way. At any time a process has a single subdirec(cid:173)
`tory of the capability directory designated as its active
`directory. A process can change its active directory to any
`
`subdirectory capabilities, circles denote operation capabilities,
`Rectangles denote
`parallelograms denote manager definition capabilities and diamonds denote cooperation
`class identifier capabilities.
`
`Bib.Manager manages an instance of a bibliography abstract data type. Create,
`Update, Print, Pwoa (Print without Annotations) and Erase are operations on the
`bibliography object. To request these operations, a process creates a port using one
`of the operation capabilities and then executes a SELECfRECEIVE, denoted by the
`SR, on the port. BIB! is a cooperation class capability and identifies a particular
`bibliography.
`
`Fig. 1. The bibliography subdirectory.
`
`subdirectory registered in its current active directory.
`(Fig. 1 presents the structure of the subdirectory used for
`a bibliography application [16].) A process may only use
`stable capabilities that are registered in its active direc(cid:173)
`tory. Each active directory has rights associated with it
`(independent of the capabilities registered in the subdi(cid:173)
`rectory) that further restrict the primitives a process may
`use to manipulate and exercise the capabilities registered
`in the directory. These rights are determined by the par(cid:173)
`ticular subdirectory capability a process uses to make the
`subdirectory its active directory.
`In addition to the capabilities in a process's active di(cid:173)
`rectory, a process may exercise the capabilities in its ca(cid:173)
`pability list (c-list). Capabilities is a process' c-list, un(cid:173)
`like those registered in the capability directory, are owned
`by the process. Such capabilities are called transient be(cid:173)
`cause they exist only for the lifetime of the owning pro(cid:173)
`cess. A transient capability comes into existence when a
`process holds a capability in its active directory (i.e., cop(cid:173)
`ies it into its c-list), receives the capability from another
`process via a port, or creates a port. In the last instance,
`the capability to access the created port is placed on the
`c-list. A process holds a capability in its active directory
`in order not ot lose the capability when it changes its ac(cid:173)
`tive directory to another subdirectory. Transient capabil(cid:173)
`ities contribute to the flexible use of capabilities in Gu(cid:173)
`tenberg without compromising the security of the system
`because the c-list may only be manipulated through kernel
`primitives.
`The kernel maintains a list of port capabilities as part
`of a process' c-list, called the process's p-list. The p-list
`is part of the capability list because a port capability is a
`transient capability that gives a process the ability to ex(cid:173)
`ecute a particular kernel primitive on the port. The pos(cid:173)
`sible kernel primitives on ports include SEND, RE(cid:173)
`CEIVE, and SELECTRECEIVE (SELECTRECEIVE is
`intended for bidirectional communication).
`Note that capabilities, ports, and the capability direc(cid:173)
`tory are kernel objects and hence can themselves be ma(cid:173)
`nipulated only through the kernel primitives defined on
`them. For instance, the capability directory is traversed
`
`

`

`638
`
`IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.5, MAY 1986
`
`and its contents modified by processes through kernel
`primitives, e.g., CHANGE-DIRECTORY, REGISTER,
`and DELETE-MANAGER. When a process requests the
`execution of a kernel primitive the kernel uses the c-list
`and the active directory of the process to check whether
`it has a legitimate privilege for executing the primitive.
`
`B. User-Defined Objects
`We now move from kernel objects to user-defined ob(cid:173)
`jects and examine how user-defined objects are shared and
`protected. By user-defined objects we mean those objects
`managed by one process but accessible by other processes
`via operations requested using ports . We are not con(cid:173)
`cerned here with objects purely local to a process since
`the Gutenberg kernel is not involved in their protection
`beyond the ordinary aspects of memory management.
`Each user-defined object is managed by a manager pro(cid:173)
`cess. The set of possible operations that may be per(cid:173)
`formed on an object are determined by the operation ca(cid:173)
`pabilities
`linked to the object's manager definition
`capability. In order for a process to request an operation
`on a shared object the process must create a port using
`one of the operation capabilities that is linked to the ob(cid:173)
`ject's manager and then US€? the port to request the partic(cid:173)
`ular operation on the object. The operation capability must
`reside in the process' active directory or c-list when the
`port is created. In this way, operation capabilities are ca(cid:173)
`pabilities to create ports to access sharable objects. For
`in Fig. 1 the only operations that can be per(cid:173)
`example,
`formed on a bibliography are those for which operation
`capabilities (such as Create) are linked to the Bib.Manager
`manager definition capability. A process may request a
`bibliography operation only if it obtains one of the oper(cid:173)
`ation capabilities in Biblio.Dir (e.g., by making Bib(cid:173)
`lio. Dir its active directory), creates a port using the op(cid:173)
`eration capability, and then uses the port to request the
`operation.
`In Gutenberg, the only way a process can request an
`operation on a user-defined object is to execute a kernel
`primitive on a port, either SEND, RECEIVE, or SELECT(cid:173)
`RECEIVE. Ports are very restrictive in how they allow
`access.to objects. First, the kernel associates the name of
`the operation in an operation capability with a port that is
`created using the capability. This association is not
`changeable and the operation is not included as a param(cid:173)
`eter to port primitives after port creation. Thus, a process
`may only use the port to request the operation for which
`the port was created . Second, each port capability entitles
`the owning process to execute only a single type of port
`primitive for sending and receiving, namely, SEND, RE(cid:173)
`CEIVE, or SELECTRECEIVE. The (single) sending or
`receiving primitive that can be executed by a client on a
`port is a parameter contained in the operation capability
`used by the client to create the port. For example, the SR
`labels (for SELECTRECEIVE) on the links between the
`operation names and Bib. Manager in Fig. 1 mean that the
`SELECTRECEIVE primitive must be used to request each
`of the bibliography operations.
`
`c. Port Primitives
`Ports are instances of an abstract data type whose man(cid:173)
`ager is the system kernel and constitute the communica(cid:173)
`tion links between processes. At any time in a port's ex(cid:173)
`istence it is linked to exactly two processes, its client and
`its server. The one-to-one nature of Gutenberg ports was
`chosen to reduce the complexity of the kernel and because
`more complex interconnections can be simulated using
`such ports [14]. Both the client and the server processes
`are limited to a small set of primitives they can execute
`on the port. Operation capabilities are used at port crea(cid:173)
`tion time to determine the limitations on the port, includ(cid:173)
`ing whether (and what kinds ot) privileges (capabilities)
`can be transferred on the port.
`re(cid:173)
`Client primitives and the corresponding server
`sponses are listed in the following table. When a port is
`created, the creator, the initial client, gets the privilege,
`termed the client privilege, to execute one of the sets of
`client primitives in the table, e.g., SEND and REVOKE.
`When a process is chosen as the server of the port, it gets
`the privilege, the server privilege, to execute the corre(cid:173)
`sponding server primitives, e.g., RECEIVE and RE(cid:173)
`FUSE.
`
`Client Primitives
`
`Server Primitives
`
`SEND
`REVOKE
`
`RECEIVE
`
`SELECTRECEIVE
`REVOKE
`
`RECEIVE
`REFUSE
`
`SEND
`REFUSE
`
`GETDETAILS
`SEND
`REFUSE
`
`Note that exactly one of the two processes has the privi(cid:173)
`lege to execute the SEND primitive on a port.
`We now give a short summary of the purposes of these
`primitives.
`(Details concerning the primitives may be
`found in [8].)
`• RECEIVE requests the next message from the port.
`The caller elects via a parameter to the call,
`to either
`block, if there is no message on the port, or execute con(cid:173)
`currently with the servicing of the request.
`• SEND puts a message on a port. The system has two
`kinds of SEND primitives: acknowledge-SEND and no(cid:173)
`acknowledge-SEND. If the SEND is an acknowledge(cid:173)
`SEND, the sending process is informed when its corre(cid:173)
`spondent over the port receives the message, and can
`choose to block until the receipt of the acknowledgment.
`• SELECTRECEIVE (only a client primitive) puts in(cid:173)
`formation, termed request details, on a port for the server
`to use in satisfying the request, and when the server re(cid:173)
`sponds to the request by executing a SEND, the server's
`reply is returned to the client as in RECEIVE. The caller
`may block until the server replies, or execute concurrently
`with the servicing of the request.
`• GETDETAILS gets request details from a port. The
`caller (the port's server) may block if there is no pending
`
`

`

`RAMAMRITHAM et al.: PRIVILEGE TRANSFER IN A PORT-BASED SYSTEM
`
`639
`
`SELECTRECEIVE, and thus no request details, on the
`port, or it may execute concurrently with the satisfaction
`of its request.
`• REFUSE rejects a client's request for service as un(cid:173)
`satisfiable and notifies the requester by setting a status.
`• REVOKE revokes privileges sent as part of request
`details by a SELECTRECEIVE (or in a SEND message
`up to receipt of the message). The details of this primitive
`are dealt with in Sections IV, V, and VI.
`The choice of these primitives in the system design was
`based on the desire to keep their number and complexity
`to a minimum while affording users a set of primitives for
`building systems of communicating processes with rea(cid:173)
`sonable ease. Thus, we have added to the basic SEND
`and RECEIVE primitives the bidirectional SELECTRE(cid:173)
`CEIVE and its receiving reciprocal GETDETAILS in or(cid:173)
`der to allow such functions as reading a record with a
`given key (the key being sent as request details) or a re(cid:173)
`mote procedure call (the procedure's parameters being
`sent as request details) to be implemented by a single
`primitive.
`In addition to its client and its server, a port has asso(cid:173)
`ciated with it the process which created it, its owner. Ini(cid:173)
`tially, the owner and the client of the port are the same
`process, but, as detailed below, the owner may transfer
`its privilege as the port's client to another