revoke

Description

Revokes permissions or roles from users or roles.

Syntax

To revoke permission to access database objects:

revoke [grant option for] 
	{all [privileges] | permission_list} 
	on { table_name [(column_list)] 
		| view_name [(column_list)] 
		| stored_procedure_name}
	from {public | name_list | role_name}
	[cascade]

To revoke permission to select built-in functions:

revoke select 
	on [builtin] built-in 
	to { name_list | role_name }

To revoke permission to create database objects, execute set proxy, or execute set session authorization:

revoke {all [privileges] | command_list } 
	from {public | name_list | role_name}

To revoke a role from a user or another role:

revoke role {role_name [, role_name ...]} from 
	{grantee [, grantee ...]}

To revoke access on some dbcc commands.

revoke dbcc {dbcc_command [on {all | database }]
		[, dbcc_command [on {all | database }], ...]} 
	from { user_list | role_list }

Parameters

all

when used to revoke permission to access database objects (the first syntax format), all revokes all permissions applicable to the specified object. All object owners can use revoke all with an object name to revoke permissions on their own objects.

Only the System Administrator or the Database Owner can revoke permission to revoke create command permissions (the second syntax format). When used by the System Administrator, revoke all revokes all create permissions (create database, create default, create procedure, create rule, create table, and create view). When the Database Owner uses revoke all, Adaptive Server revokes all create permissions except create database, and prints an informational message.

all does not apply to set proxy or set session authorization.

permission_list

is a list of permissions to revoke. If more than one permission is listed, separate them with commas. The following table illustrates the access permissions that can be granted and revoked on each type of object:

Object	permission_list can include
Table	select, insert, delete, update, references
View	select, insert, delete, update
Column	select, update, references Column names can be specified in either permission_list or column_list (see Example 2).
Stored procedure	execute

Permissions can be revoked only by the user who granted them.

function_list

is a built-in function. Specifying built-in functions allows you to differentiate between a table and a grantable built-in function with the same name. The functions are set_appcontext, get_appcontext, list_appcontext, and rm_appcontext.

command_list

is a list of commands. If more than one command is listed, separate them with commas. The command list can include create database, create default, create procedure, create rule, create table, create view, set proxy, or set session authorization. create database permission can be revoked only by a System Administrator and only from within the master database.

set proxy and set session authorization are identical; the only difference is that set session authorization follows the SQL standard, and set proxy is a Transact-SQL extension. Revoking permission to execute set proxy or set session authorization revokes permission to become another user in the server. Permissions for set proxy or set session authorization can be revoked only by a System Security Officer, and only from within the master database.

table_name

is the name of the table on which you are revoking permissions. The table must be in your current database. Only one object can be listed for each revoke statement.

column_list

is a list of columns, separated by commas, to which the privileges apply. If columns are specified, only select and update permissions can be revoked.

view_name

is the name of the view on which you are revoking permissions. The view must be in your current database. Only one object can be listed for each revoke statement.

stored _procedure_name

is the name of the stored procedure on which you are revoking permissions. The stored procedure must be in your current database. Only one object can be listed for each revoke statement.

public

is all users. For object access permissions, public excludes the object owner. For object creation permissions or set proxy authorizations, public excludes the Database Owner. You cannot grant permissions with grant option to “public” or to other groups or roles.

name_list

is a list of user and/or group names, separated by commas.

role

is the name of a system or user-defined role. Use revoke role to revoke granted roles from roles or users.

role_name

is the name of a system or user-defined role. This allows you to revoke permissions from all users who have been granted a specific role. The role name can be either a system role or a user-defined role created by a System Security Officer with create role. Either type of role can be granted to a user with the grant role command. In addition, sp_role can be used to grant system roles.

grantee

is the name of a system role, user-defined role, or a user, from whom you are revoking a role.

grant option for

revokes with grant option permissions, so that the user(s) specified in name_list can no longer grant the specified permissions to other users. If those users have granted permissions to other users, you must use the cascade option to revoke permissions from those users. The user specified in name_list retains permission to access the object, but can no longer grant access to other users. grant option for applies only to object access permissions, not to object creation permissions.

cascade

revokes the specified object access permissions from all users to whom the revokee granted permissions. Applies only to object access permissions, not to object creation permissions. When you use revoke without grant option for, permissions granted to other users by the revokee are also revoked: the cascade occurs automatically.

dbcc_command

is the name of the dbcc command you are granting. It cannot be a variable. Table 1-33 lists the valid revoke dbcc commands.

database

is the name of the database on which you are granting permissions. It is used with database-specific dbcc commands to grant permission only on the target database. The grantee must be a valid user in the target database. database conforms to the rules for identifiers and cannot be a variable.

If there are multiple granted actions in the same command, database must be unique.

See “on all | database parameter and server-level commands” for more information.

user_list

is a list of users to whom you are granting the permission, and cannot be a variable.

role_list

is a list of the name of system or user-defined roles to whom you are granting the permission, and cannot be a variable.

You cannot grant or revoke dbcc commands to public or groups.

Examples

Example 1

Revokes insert and delete permissions on the titles table from Mary and the “sales” group:

revoke insert, delete 
on titles 
from mary, sales

Example 2

Revokes select permission on the get_appcontext function to “public” (which includes all users):

revoke select on builtin get_appcontext to public 

Compare this to the following, which revokes select permission on a table called get_appcontext, if a table with that name exists:

revoke select on get_appcontext to public

Example 3

Two ways to revoke update permission on the price and advance columns of the titles table from “public”:

revoke update
on titles (price, advance)
from public

or:

revoke update (price, advance)
on titles
from public

Example 4

Revokes permission from Mary and John to use the create database and create table commands. Because create database permission is being revoked, this command must be executed by a System Administrator from within the master database. Mary and John’s create table permission is revoked only within the master database:

revoke create database, create table from mary, john

Example 5

Revokes permission from Harry and Billy to execute either set proxy or set session authorization to impersonate another user in the server:

revoke set proxy from harry, billy

Example 6

Revokes permission from users with sso_role to execute either set proxy or set session authorization:

revoke set session authorization from sso_role

Example 7

Revokes permission from users with vip_role to impersonate another user in the server. vip_role must be a role defined by a System Security Officer with the create role command:

revoke set proxy from vip_role

Example 8

Revokes all object creation permissions from Mary in the current database:

revoke all from mary

Example 9

Revokes all object access permissions on the titles table from Mary:

revoke all on titles from mary

Example 10

Two ways to revoke Tom’s permission to create a referential integrity constraint on another table that refers to the price and advance columns in the titles table:

revoke references
on titles (price, advance)
from tom

or:

revoke references (price, advance)
on titles
from tom

Example 11

Revokes permission to execute new_sproc from all users who have been granted the “operator” role:

revoke execute on new_sproc from oper_role

Example 12

Revokes John’s permission to grant insert, update, and delete permissions on the authors table to other users. Also revokes from other users any such permissions that John has granted:

revoke grant option for
insert, update, delete
on authors
from john
cascade

Example 13

Revokes “doctor_role” from “specialist_role”:

revoke role doctor_role from specialist_role

Example 14

Revokes “doctor_role” and “surgeon_role” from “specialist_role” and “intern_role”, and from users Mary and Tom:

revoke role doctor_role, surgeon_role from specialist_role, intern_role, mary, tom

Example 15

Revokes dbcc privileges from Frank:

1> use pubs2
2> go
1> revoke dbcc checkdb on pubs2 from checkdb_role
2> go
1> use master
2> go
1> revoke dbcc checkdb on all to frank
2> go
...

Usage

• See the grant command for more information about permissions.

• You can revoke permissions only on objects in your current database.

• You can revoke only permissions that were granted by you.

• You cannot revoke a role from a user while the user is logged in.

• grant and revoke commands are order sensitive. When there is a conflict, the command issued most recently takes effect.

• The word to can be substituted for the word from in the revoke syntax.

• If you do not specify grant option for in a revoke statement, with grant option permissions are revoked from the user along with the specified object access permissions. In addition, if the user has granted the specified permissions to any other users, all of those permissions are revoked. In other words, the revoke cascades.

• A grant statement adds one row to the sysprotects system table for each user, group, or role that receives the permission. If you subsequently revoke the permission from the user or group, Adaptive Server removes the row from sysprotects. If you revoke the permission from only selected group members, but not from the entire group to which it was granted, Adaptive Server retains the original row and adds a new row for the revoke.

• Permission to issue create trigger is granted to users by default. When you revoke permission for a user to create triggers, a revoke row is added in the sysprotects table for that user. To grant permission to issue create trigger, you must issue two grant commands. The first command removes the revoke row from sysprotects; the second inserts a grant row. If you revoke permission to create triggers, the user cannot create triggers even on tables that the user owns. Revoking permission to create triggers from a user affects only the database where the revoke command was issued.

Using the cascade option

• revoke grant option revokes the user’s ability to grant the specified permission to other users, but does not revoke the permission itself from that user. If the user has granted that permission to others, you must use the cascade option; otherwise, you receive an error message and the revoke fails.

  For example, say you revoke the with grant option permissions from the user Bob on titles, with this statement:

  revoke grant option for select
  on titles
  from bob
  cascade
  

  • If Bob has not granted this permission to other users, this command revokes his ability to do so, but he retains select permission on the titles table.

  • If Bob has granted this permission to other users, you must use the cascade option. If you do not, you receive an error message and the revoke fails. cascade revokes this select permission from all users to whom Bob has granted it, as well as their ability to grant it to others.

• You cannot use revoke with the cascade option to revoke privileges granted by the table owner. For example, the owner of a table (UserA) can grant privileges to another user (UserB) as in this scenario:

  create table T1 (...)
  grant select on T1 to UserB
  

  However, the System Administrator cannot revoke UserB’s privileges using the revoke privileges command with the cascade option as in this statement:

  revoke select on T1 from UserA cascade
  

  This statement revokes the select privileges of the table owner, but does not revoke those privileges from UserB.

  By default, all data manipulation language (DML) operations are revoked implicitly for users other than the table owner. Because the sysprotects table contains no records indicating that the table owner has granted and then revoked privileges, the cascade option is not invoked.You must revoke explicitly the select privilege from UserB.

Revoking set proxy and set session authorization

• To revoke set proxy or set session authorization permission, or to revoke roles, you must be a System Security Officer, and you must be in the master database.

• set proxy and set session authorization are identical, with one exception: set session authorization follows the SQL standard. If you are concerned about using only SQL standard commands and syntax, use set session authorization.

• revoke all does not include set proxy or set session authorization permissions.

Revoking from roles, users and groups

• Permissions granted to roles override permissions granted to individual users or groups. Therefore, if you revoke a permission from a user who has been granted a role, and the role has that same permission, the user retains it. For example, say John has been granted the System Security Officer role, and sso_role has been granted permission on the sales table. If John’s individual permission on sales is revoked, he can still access sales because his role permissions override his individual permissions.

• Revoking a specific permission from “public” or from a group also revokes it from users who were individually granted the permission.

• Database user groups allow you to grant or revoke permissions to more than one user at a time. A user is always a member of the default group, “public” and can be a member of only one other group. Adaptive Server’s installation script assigns a set of permissions to “public.”

  Create groups with sp_addgroup and remove groups with sp_dropgroup. Add new users to a group with sp_adduser. Change a user’s group membership with sp_changegroup. To display the members of a group, use sp_helpgroup.

revoke dbcc command options

Table 1-33 lists the valid revoke dbcc commands.

All of the options in Table 1-33 are database-level commands except for tune, which is a server-level command.

See Chapter 25, “Checking Database Consistency” in the System Administration Guide for more information on these dbcc commands.

on all | database parameter and server-level commands

The on database parameter specifies the database on which to invoke the database-level revoke dbcc command. Because on master grants the ability to use dbcc commands on all databases, on master is the same as on all. You must be in the master database to use either the on all and on master parameters.

Neither the on database nor on all parameters work when invoking a server-level grant dbcc command such as dbcc tune, because by doing so, you are forcing a server-level command to restrict itself to individual databases. For this reason, using the server-level revoke dbcc tune on master command raises an error.

Standards

ANSI SQL – Compliance level: Transact-SQL extension.

Permissions

Database object access revoke permission for database objects defaults to object owners. An object owner can revoke permission from other users on his or her own database objects.

Command execution Only a System Administrator can revoke create database permission, and only from the master database. Only a System Security Officer can revoke create trigger permission.

Proxy and session authorization Only a System Security Officer can revoke set proxy or set session authorization, and only from the master database.

Roles You can revoke roles only from the master database. Only a System Security Officer can revoke sso_role, oper_role, or a user-defined role from a user or a role. Only System Administrators can revoke sa_role from a user or a role. Only a user who has both sa_role and sso_role can revoke a role that includes sa_role.

Database consistency checking Only System Administrators can run revoke dbcc commands. Database Owners cannot run revoke dbcc.

See also

Commands grant, setuser, set

Functions proc_role

System procedures sp_activeroles, sp_adduser, sp_changedbowner, sp_changegroup, sp_displaylogin, sp_displayroles, sp_dropgroup, sp_dropuser, sp_helpgroup, sp_helprotect, sp_helpuser, sp_modifylogin, sp_role

---

Copyright © 2004. Sybase Inc. All rights reserved.

View this book as PDF