REVOKE [ GRANT OPTION FOR ]
{ { SELECT | INSERT | UPDATE | DELETE | REFERENCES } [,...] | ALL [ PRIVILEGES ] }
ON [ TABLE ] tablename [, ...]
FROM { [ GROUP ] rolename | PUBLIC } [, ...] [ CASCADE | RESTRICT ]
REVOKE [ GRANT OPTION FOR ]
{ { CREATE | CONNECT } [,...] | ALL [ PRIVILEGES ] } ON DATABASE dbname [, ...]
FROM { [ GROUP ] rolename | PUBLIC } [, ...] [ CASCADE | RESTRICT ]
REVOKE [ GRANT OPTION FOR ]
{ { CREATE | USAGE | INSTALL FILE | CREATE FUNCTION } [,...] | ALL [PRIVILEGES] } ON SCHEMA schemaname [, ...]
FROM { [ GROUP ] rolename | PUBLIC } [, ...] [ CASCADE | RESTRICT ]
REVOKE [ GRANT OPTION FOR ] EXECUTE [ PRIVILEGES ]
ON FUNCTION [schemaname.]funcname
FROM{ [ GROUP ] rolename | PUBLIC } [, ...] REVOKE [ ADMIN OPTION FOR ]
role [, ...] FROM username [, ...] [ CASCADE | RESTRICT ];
Description
The REVOKE command revokes previously granted privileges from one or more roles or users. The keyword PUBLIC refers to the implicitly defined group of all roles.
REVOKE Aster Data proprietary and confidential
Note that any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is now a member of, and privileges granted to PUBLIC. Thus, for example, revoking SELECT privilege from PUBLIC does not necessarily mean that all roles have lost SELECT privilege on the object: those who have it granted directly or via another role will still have it.
If GRANT OPTION FOR is specified, only the grant option for the privilege is revoked, not the privilege itself. Otherwise, both the privilege and the grant option are revoked.
If a user holds a privilege with grant option and has granted it to other users then the privileges held by those other users are called dependent privileges. If the privilege or the grant option held by the first user is being revoked and dependent privileges exist, those dependent privileges are also revoked if CASCADE is specified, else the revoke action will fail. This recursive revocation only affects privileges that were granted through a chain of users that is traceable to the user that is the subject of this REVOKE command. Thus, the affected users may effectively keep the privilege if it was also granted through other users.
When revoking membership in a role, GRANT OPTION is instead called ADMINOPTION, but the behavior is similar.
Notes
Revoking Users Rights to Create Tables The CREATE privilege on a database governs a user’s right to create schemas, not tables. Therefore, REVOKE CREATE ON DATABASE... only removes a user’s right to create schemas in the database. He or she can still create tables. To limit users’ rights to create tables, you can follow one of the approaches below:
• Approach 1: Revoke the user’s connect privilege on the database. This is a broad-brushed approach; it denies the user’s right to run any queries at all on the database. For a less restrictive approach, do one of the following, instead:
• Approach 2: Revoke the user’s CREATE privilege on the schema in which you want to restrict this right. For example, if your users work only in the PUBLIC schema, then you can revoke the CREATE privilege on the PUBLIC schema from the PUBLIC role, and then grant
CREATE on the PUBLIC schema back to OWNER and to the other users or roles who are allowed to create tables.
• Approach 3: You can use schemas to manage rights:
• Revoke the CREATE privilege on the PUBLIC schema from the PUBLIC role.
• Create appropriate schemas in each database, and grant CREATE on each schema appropriately. For example, in one database with relatively free permissions you would grant CREATE on its schema to PUBLIC role, but in other, more restricted databases you would grant CREATE on their schemas only to those users and roles whom you wish to grant rights.
Revoking Rights to Objects in a Schema For information on using REVOKE USAGE ON SCHEMA to limit user’s access to objects contained in a schema, see the note in “USAGE” on page V-62.
Which Privileges Can I Revoke? A user can only revoke privileges that were granted directly by that user. If, for example, user A has granted a privilege with grant option to user B, and user B has in turned granted it to user C, then user A cannot revoke the privilege directly from C. Instead, user A could revoke the grant option from user B and use the CASCADE option so that the privilege is in turn revoked from user C. For another example, if both A and B have granted the same privilege to C, A can revoke his own grant but not the grant from B, so C will still effectively have the privilege.
Aster Data proprietary and confidential REVOKE
When a non-owner of an object attempts to REVOKE privileges on the object, the command will fail outright if the user has no privileges whatsoever on the object. As long as some privilege is available, the command will proceed, but it will revoke only those privileges for which the user has grant options. The REVOKE ALL PRIVILEGES forms will issue a warning message if no grant options are held, while the other forms will issue a warning if grant options for any of the privileges specifically named in the command are not held. (In principle these statements apply to the object owner as well, but since the owner is always treated as holding all grant options, the cases can never occur.)
REVOKE can also be done by a role that is not the owner of the affected object, but is a member of the role that owns the object, or is a member of a role that holds privileges WITH GRANT OPTION on the object. In this case the command is performed as though it were issued by the containing role that actually owns the object or holds the privileges WITH GRANT OPTION. For example, if table t1 is owned by role g1, of which role u1 is a member, then u1 can revoke privileges on t1 that are recorded as being granted by g1. This would include grants made by u1 as well as by other members of role g1.
If the role executing REVOKE holds privileges indirectly via more than one role membership path, it is unspecified which containing role will be used to perform the command.
Roles and privleges are one factor that determines what a user can do in the AMC. For more information on what determines the actions a user may perform in the AMC, see “Allowed Administrative Actions” on page III-23.
Examples
Revoke connect privilege for user mjones on database imdb:
REVOKE CONNECT ON DATABASE imdb FROM mjones;
Revoke insert privilege for the public on table films:
REVOKE INSERT ON films FROM PUBLIC;
Revoke all privileges for the public on database films:
REVOKE ALL PRIVILEGES ON DATABASE films FROM PUBLIC;
Revoke membership in role admins from user jstrummer:
REVOKE admins FROM jstrummer;
Compatibility
The compatibility notes of the GRANT command apply analogously to REVOKE.
One of RESTRICT or CASCADE is required according to the standard, but Aster Database assumes RESTRICT by default.
See Also
ROLLBACK Aster Data proprietary and confidential