SYNVER is an automatic programming system for the synthesis of solutions to problems of synchronization among concurrent processes from specifications written in a high level assertion language (SAL). The correctness of the solutions constructed by SYNVER follows from the soundness of the synthesizer itself and from a verification phase which is applied to the specifications. This verification phase is the main topic of this paper. To provide context for the verification the paper includes a discussion of synchronization problems and a brief overview of both the SYNVER system and the SAL specification language. A formal definition of the correctness of a SAL specification is then presented along with algorithms which may be used to determine if a given specification is correct.

A multi-user data base system must permit users to selectively share data, while retaining the ability to restrict data access. There must be a mechanism to provide protection and security, permitting information to be accessed only by properly authorized users. Further, when tables or restricted views of tables are created and destroyed dynamically, the granting, authentication, and revocation of authorization to use them must also be dynamic. We discuss each of these issues and their solutions in the context of the relational data base management system, System R.When a data base user creates a table, he is fully and solely authorized to perform actions upon it such as read, insert, update, and delete. If he wishes, he may explicitly grant to any other user any or all of his privileges on the table. In addition, he may specify that that user is authorized to further grant these privileges to other users. The result is a directed graph of granted privileges originating from the table creator.At some later time, a user A may revoke some or all of the privileges which he previously granted to another user B. This action usually revokes the entire subgraph of the grants originating from A's grant to B. It may be, however, that B will still possess the revoked privileges by means of a grant from another user C, and therefore some or all of B's grants should not be revoked. We discuss this problem in detail and present an algorithm for detecting exactly which of B'S grants should be revoked.Because revocation may be performed dynamically, a user's authorization for a table must be checked dynamically. We present a scheme which attempts to minimize the cost of such revalidation.

System R is a database management system which provides a high level relational data interface. The systems provides a high level of data independence by isolating the end user as much as possible from underlying storage structures. The system permits definition of a variety of relational views on common underlying data. Data control features are provided, including authorization, integrity assertions, triggered transactions, a logging and recovery subsystem, and facilities for maintaining data consistency in a shared-update environment. This paper contains a description of the overall architecture and design of the system. At the present time the system is being implemented and the design evaluated. We emphasize that System R is a vehicle for research in database architecture, and is not planned as a product.

A multiuser database system must selectively permit users to share data, while retaining the ability to restrict data access. There must be a mechanism to provide protection and security, permitting information to be accessed only by properly authorized users. Further, when tables or restricted views of tables are created and destroyed dynamically, the granting, authentication, and revocation of authorization to use them must also be dynamic. Each of these issues and their solutions in the context of the relational database management system System R are discussed. When a database user creates a table, he is fully and solely authorized to perform upon it actions such as read, insert, update, and delete. He may explicitly grant to any other user any or all of his privileges on the table. In addition he may specify that that user is authorized to further grant these privileges to still other users. The result is a directed graph of granted privileges originating from the table creator. At some later time a user A may revoke some or all of the privileges which he previously granted to another user B. This action usually revokes the entire subgraph of the grants originating from A's grant to B. It may be, however, that B will still possess the revoked privileges by means of a grant from another user C, and therefore some or all of B's grants should not be revoked. This problem is discussed in detail, and an algorithm for detecting exactly which of B's grants should be revoked is presented.