A Survey of Delegation from an RBAC Perspective <s> B. Discretionary Access Control in Relational Databases <s> 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. <s> BIB001 </s> A Survey of Delegation from an RBAC Perspective <s> B. Discretionary Access Control in Relational Databases <s> Griffiths and Wade ( ACM Trans. Database Syst. 1,3, (Sept. 1976), 242-255) have defined a dynamic authorization mechanism that goes beyond the traditional password approach. A database user can grant or revoke privileges (such as to read, insert, or delete) on a file that he has created. Furthermore, he can authorize others to grant these same privileges. The database management system keeps track of a directed graph, emanating from the creator, of granted privileges. The nodes of the graph correspond to users, and the edges (each of which is labeled with a timestamp) correspond to grants. The edges are of two types, corresponding to whether or not the recipient of the grant has been given the option to make further grants of this privilege. Furthermore, for each pair A, B of nodes, there can be no more than one edge of each type from A to B . We modify this approach by allowing graphs in which there can be multiple edges of each type from one node to another. We prove correctness (in a certain strong sense) for our modified authorization mechanism. Further, we show by example that under the original mechanism, the system might forbid some user from exercising or granting a privilege that he “should” be allowed to exercise or grant. <s> BIB002
Discretionary access control in relational databases is embodied in the GRANT and REVOKE statements, which are part of the SQL standard  . The GRANT statement allows a user with control (usually the owner of the table) to grant some or all of the access modes on some or all of the columns of a table to other users. These permissions can be accompanied by the grant option, which allows the grantee to further pass on the permission (similar to the copy flag above). In the original paper describing access control for relational databases, Griffiths and Wade BIB001 discuss the problem which occurs when a user has been granted a permission in more than one way. Each such grant is at the end of a sequence of grants from the original owner, and these sequences may or may not overlap. When a permission is revoked, each permission whose existence is based on the revoked permission should also be revoked. This concept is called cascading revoke. To do this correctly, timestamps must be kept for each of possibly multiple granting actions BIB002 . In relational databases, there is only one command, the GRANT statement, for assigning permissions to users. If the database administrator initially designs the database, and is the de facto owner of all the tables, then he or she can assign permissions to various users with grant option. These users can then perform a delegation as defined in Definition 1 by using the GRANT statement at run time. On the other hand, a relational database could be designed and created by a collection of users, who retain ownership during the life of the database. If these users grant permission to others, but never do so "with grant option", and never at run time, then the system exhibits administration of permissions but no delegation. Thus it is difficult to distinguish delegation from administration in relational databases because the set of commands for controlling access is so limited. The same confusion exists in all systems exhibiting discretionary access control, where a small number of commands are available to confer access to another user, making it difficult to distinguish between administration and delegation. Role-based access control, as we shall see in the next section, offers a richer model within which to distinguish all the nuances possible in delegation.