GRANT Object Permissions (Transact-SQL)
Grants permissions on a table, view, table-valued function, stored procedure, extended stored procedure, scalar function, aggregate function, service queue, or synonym.
GRANT <permission> [ ,...n ] ON
[ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ]
TO <database_principal> [ ,...n ]
[ WITH GRANT OPTION ]
[ AS <database_principal> ]
<permission> ::=
ALL [ PRIVILEGES ] | permission [ ( column [ ,...n ] ) ]
<database_principal> ::=
Database_user
| Database_role
| Application_role
| Database_user_mapped_to_Windows_User
| Database_user_mapped_to_Windows_Group
| Database_user_mapped_to_certificate
| Database_user_mapped_to_asymmetric_key
| Database_user_with_no_login
Important
|
|---|
|
A combination of ALTER and REFERENCE permissions in some cases could allow the grantee to view data or execute unauthorized functions. For example: A user with ALTER permission on a table and REFERENCE permission on a function can create a computed column over a function and have it be executed. In this case the user would also need SELECT permission on the computed column. |
Information about objects is visible in various catalog views. For more information, see Object Catalog Views (Transact-SQL).
An object is a schema-level securable contained by the schema that is its parent in the permissions hierarchy. The most specific and limited permissions that can be granted on an object are listed in the following table, together with the more general permissions that include them by implication.
|
Object permission |
Implied by object permission |
Implied by schema permission |
|---|---|---|
|
ALTER |
CONTROL |
ALTER |
|
CONTROL |
CONTROL |
CONTROL |
|
DELETE |
CONTROL |
DELETE |
|
EXECUTE |
CONTROL |
EXECUTE |
|
INSERT |
CONTROL |
INSERT |
|
RECEIVE |
CONTROL |
CONTROL |
|
REFERENCES |
CONTROL |
REFERENCES |
|
SELECT |
RECEIVE |
SELECT |
|
TAKE OWNERSHIP |
CONTROL |
CONTROL |
|
UPDATE |
CONTROL |
UPDATE |
|
VIEW CHANGE TRACKING |
CONTROL |
VIEW CHANGE TRACKING |
|
VIEW DEFINITION |
CONTROL |
VIEW DEFINITION |
The grantor (or the principal specified with the AS option) must have either the permission itself with GRANT OPTION, or a higher permission that implies the permission being granted.
If you are using the AS option, the following additional requirements apply.
|
AS |
Additional permission required |
|---|---|
|
Database user |
IMPERSONATE permission on the user, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Database user mapped to a Windows login |
IMPERSONATE permission on the user, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Database user mapped to a Windows Group |
Membership in the Windows group, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Database user mapped to a certificate |
Membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Database user mapped to an asymmetric key |
Membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Database user not mapped to any server principal |
IMPERSONATE permission on the user, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Database role |
ALTER permission on the role, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
|
Application role |
ALTER permission on the role, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role. |
A. Granting SELECT permission on a table
The following example grants SELECT permission to user RosaQdM on table Person.Address in the AdventureWorks2012 database.
USE AdventureWorks2012; GRANT SELECT ON OBJECT::Person.Address TO RosaQdM; GO
B. Granting EXECUTE permission on a stored procedure
The following example grants EXECUTE permission on stored procedure HumanResources.uspUpdateEmployeeHireInfo to an application role called Recruiting11.
USE AdventureWorks2012;
GRANT EXECUTE ON OBJECT::HumanResources.uspUpdateEmployeeHireInfo
TO Recruiting11;
GO
C. Granting REFERENCES permission on a view with GRANT OPTION
The following example grants REFERENCES permission on column BusinessEntityID in view HumanResources.vEmployee to user Wanida with GRANT OPTION.
USE AdventureWorks2012;
GRANT REFERENCES (BusinessEntityID) ON OBJECT::HumanResources.vEmployee
TO Wanida WITH GRANT OPTION;
GO
D. Granting SELECT permission on a table without using the OBJECT phrase
The following example grants SELECT permission to user RosaQdM on table Person.Address in the AdventureWorks2012 database.
USE AdventureWorks2012; GRANT SELECT ON Person.Address TO RosaQdM; GO
E. Granting SELECT permission on a table to a domain account
The following example grants SELECT permission to user AdventureWorks2012\RosaQdM on table Person.Address in the AdventureWorks2012 database.
USE AdventureWorks2012; GRANT SELECT ON Person.Address TO [AdventureWorks2012\RosaQdM]; GO
F. Granting EXECUTE permission on a procedure to a role
The following example creates a role and then grants EXECUTE permission to the role on procedure uspGetBillOfMaterials in the AdventureWorks2012 database.
USE AdventureWorks2012; CREATE ROLE newrole ; GRANT EXECUTE ON dbo.uspGetBillOfMaterials TO newrole ; GO