Topic Status: Some information in this topic is preview and subject to change in future releases. Preview information describes new features or changes to existing features in Microsoft SQL Server 2016 Community Technology Preview 2 (CTP2).
Grants permissions on a securable to a principal. The general concept is to GRANT <some permission> ON <some object> TO <some user, login, or group>. For a general discussion of permissions, see Permissions (Database Engine).
Applies to: SQL Server (SQL Server 2008 through current version), Azure SQL Database.
The full syntax of the GRANT statement is complex. The syntax diagram above was simplified to draw attention to its structure. Complete syntax for granting permissions on specific securables is described in the topics listed below.
The REVOKE statement can be used to remove granted permissions, and the DENY statement can be used to prevent a principal from gaining a specific permission through a GRANT.
Granting a permission removes DENY or REVOKE of that permission on the specified securable. If the same permission is denied at a higher scope that contains the securable, the DENY takes precedence. But revoking the granted permission at a higher scope does not take precedence.
Database-level permissions are granted within the scope of the specified database. If a user needs permissions to objects in another database, create the user account in the other database, or grant the user account access to the other database, as well as the current database.
A table-level DENY does not take precedence over a column-level GRANT. This inconsistency in the permissions hierarchy has been preserved for the sake of backward compatibility. It will be removed in a future release.
The sp_helprotect system stored procedure reports permissions on a database-level securable.
The GRANT … WITH GRANT OPTION specifies that the security principal receiving the permission is given the ability to grant the specified permission to other security accounts. When the principal that receives the permission is a role or a Windows group, the AS clause must be used when the object permission needs to be further granted to users who are not members of the group or role. Because only a user, rather than a group or role, can execute a GRANT statement, a specific member of the group or role must use the AS clause to explicitly invoke the role or group membership when granting the permission. The following example shows how the WITH GRANT OPTION is used when granted to a role or Windows group.
-- Execute the following as a database owner GRANT EXECUTE ON TestProc TO TesterRole WITH GRANT OPTION; EXEC sp_addrolemember TesterRole, User1; -- Execute the following as User1 -- The following fails because User1 does not have the permission as the User1 GRANT EXECUTE ON TestMe TO User2; -- The following succeeds because User1 invokes the TesterRole membership GRANT EXECUTE ON TestMe TO User2 AS TesterRole;
For a poster sized chart of all Database Engine permissions in pdf format, see http://go.microsoft.com/fwlink/?LinkId=229142.
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 using the AS option, additional requirements apply. See the securable-specific topic for details.
Object owners can grant permissions on the objects they own. Principals with CONTROL permission on a securable can grant permission on that securable.
Grantees of CONTROL SERVER permission, such as members of the sysadmin fixed server role, can grant any permission on any securable in the server. Grantees of CONTROL permission on a database, such as members of the db_owner fixed database role, can grant any permission on any securable in the database. Grantees of CONTROL permission on a schema can grant any permission on any object within the schema.
The following table lists the securables and the topics that describe the securable-specific syntax.
Remote Service Binding
Search Property List
XML Schema Collection