Permissions (Database Engine)

Applies to: SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) SQL analytics endpoint in Microsoft Fabric Warehouse in Microsoft Fabric SQL database in Microsoft Fabric

Every SQL Server securable has associated permissions that can be granted to a principal. Permissions in the Database Engine are managed at the server level assigned to logins and server roles, and at the database level assigned to database users and database roles. The model for Azure SQL Database has the same system for the database permissions, but the server level permissions aren't available. This article contains the complete list of permissions. For a typical implementation of the permissions, see Getting Started with Database Engine Permissions.

The total number of permissions for SQL Server 2022 (16.x) is 292. Azure SQL Database exposes 292 permissions. Most permissions apply to all platforms, but some don't. For example, most server level permissions can't be granted on Azure SQL Database, and a few permissions only make sense on Azure SQL Database. New permissions are being introduced gradually with new releases. SQL Server 2019 (15.x) exposes 248 permissions.SQL Server 2017 (14.x) exposed 238 permissions. SQL Server 2016 (13.x) exposed 230 permissions. SQL Server 2014 (12.x) exposed 219 permissions. SQL Server 2012 (11.x) exposed 214 permissions. SQL Server 2008 R2 (10.50.x) exposed 195 permissions. The sys.fn_builtin_permissions article specifies which permissions are new in recent versions.

In SQL database in Microsoft Fabric, only database-level users and roles are supported. Server-level logins, roles, and the sa account are not available. In SQL database in Microsoft Fabric, Microsoft Entra ID for database users is the only supported authentication method. For more information, see Authorization in SQL database in Microsoft Fabric.

Once you understand the permissions required, you can apply server level permissions to logins or server roles, and database level permissions to users or database roles, by using the GRANT, REVOKE, and DENY statements. For example:

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

For tips on planning a permissions system, see Getting Started with Database Engine Permissions.

Permissions naming conventions

The following describes the general conventions that are followed for naming permissions:

• CONTROL

  Confers ownership-like capabilities on the grantee. The grantee effectively has all defined permissions on the securable. A principal that has been granted CONTROL can also grant permissions on the securable. Because the SQL Server security model is hierarchical, CONTROL at a particular scope implicitly includes CONTROL on all the securables under that scope. For example, CONTROL on a database implies all permissions on the database, all permissions on all assemblies in the database, all permissions on all schemas in the database, and all permissions on objects within all schemas within the database.

• ALTER

  Confers the ability to change the properties, except ownership, of a particular securable. When granted on a scope, ALTER also bestows the ability to alter, create, or drop any securable that is contained within that scope. For example, ALTER permission on a schema includes the ability to create, alter, and drop objects from the schema.

• ALTER ANY <Server Securable>, where Server Securable can be any server securable.

  Confers the ability to create, alter, or drop individual instances of the Server Securable. For example, ALTER ANY LOGIN confers the ability to create, alter, or drop any login in the instance.

• ALTER ANY <Database Securable>, where Database Securable can be any securable at the database level.

  Confers the ability to CREATE, ALTER, or DROP individual instances of the Database Securable. For example, ALTER ANY SCHEMA confers the ability to create, alter, or drop any schema in the database.

• TAKE OWNERSHIP

  Enables the grantee to take ownership of the securable on which it is granted.

• IMPERSONATE <Login>

  Enables the grantee to impersonate the login.

• IMPERSONATE <User>

  Enables the grantee to impersonate the user.

• CREATE <Server Securable>

  Confers to the grantee the ability to create the Server Securable.

• CREATE <Database Securable>

  Confers to the grantee the ability to create the Database Securable.

• CREATE <Schema-contained Securable>

  Confers the ability to create the schema-contained securable. However, ALTER permission on the schema is required to create the securable in a particular schema.

• VIEW DEFINITION

  Enables the grantee to access metadata.

• REFERENCES

  The REFERENCES permission on a table is needed to create a FOREIGN KEY constraint that references that table.

  The REFERENCES permission is needed on an object to create a FUNCTION or VIEW with the WITH SCHEMABINDING clause that references that object.

Chart of SQL Server permissions

The following image shows the permissions and their relationships to each other. Some of the higher level permissions (such as CONTROL SERVER) are listed many times. In this article, the poster is far too small to read. You can download the full-sized Database Engine Permissions Poster in PDF format.

Permissions applicable to specific securables

The following table lists major classes of permissions and the kinds of securables to which they might be applied.

SQL Server permissions

The following table provides a complete list of SQL Server permissions. Azure SQL Database permissions are only available for base securables that are supported. Server level permissions can't be granted in Azure SQL Database, however in some cases database permissions are available instead.

New granular permissions added to SQL Server 2022

The following permissions are added to SQL Server 2022:

• 10 new permissions have been added to allow access to system metadata.

• 18 new permissions have been added for extended events.

• 9 new permissions have been added with regard to security-related objects.

• 4 permissions have been added for Ledger.

• 3 additional database permissions.

For more information, see New granular permissions for SQL Server 2022 and Azure SQL to improve adherence with PoLP.

Access to system metadata permissions

Server level:

• VIEW ANY SECURITY DEFINITION
• VIEW ANY PERFORMANCE DEFINITION
• VIEW SERVER SECURITY STATE
• VIEW SERVER PERFORMANCE STATE
• VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION

Database level:

• VIEW DATABASE SECURITY STATE
• VIEW DATABASE PERFORMANCE STATE
• VIEW SECURITY DEFINITION
• VIEW PERFORMANCE DEFINITION
• VIEW CRYPTOGRAPHICALLY SECURED DEFINITION

Extended events permissions

Server level:

• CREATE ANY EVENT SESSION
• DROP ANY EVENT SESSION
• ALTER ANY EVENT SESSION OPTION
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• ALTER ANY EVENT SESSION ENABLE
• ALTER ANY EVENT SESSION DISABLE
• ALTER ANY EVENT SESSION ADD TARGET
• ALTER ANY EVENT SESSION DROP TARGET

All of these permissions are under the same parent-permission: ALTER ANY EVENT SESSION

Database level:

• CREATE ANY DATABASE EVENT SESSION
• DROP ANY DATABASE EVENT SESSION
• ALTER ANY DATABASE EVENT SESSION OPTION
• ALTER ANY DATABASE EVENT SESSION ADD EVENT
• ALTER ANY DATABASE EVENT SESSION DROP EVENT
• ALTER ANY DATABASE EVENT SESSION ENABLE
• ALTER ANY DATABASE EVENT SESSION DISABLE
• ALTER ANY DATABASE EVENT SESSION ADD TARGET
• ALTER ANY DATABASE EVENT SESSION DROP TARGET

All these permissions are under the same parent-permission: ALTER ANY DATABASE EVENT SESSION

Security-related object permissions

• CONTROL (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• REFERENCES (CREDENTIAL)
• UNMASK (OBJECT)
• UNMASK (SCHEMA)
• VIEW ANY ERROR LOG
• VIEW SERVER SECURITY AUDIT
• VIEW DATABASE SECURITY AUDIT

Ledger permissions

• ALTER LEDGER
• ALTER LEDGER CONFIGURATION
• ENABLE LEDGER
• VIEW LEDGER CONTENT

Other database permissions

• ALTER ANY EXTERNAL JOB
• ALTER ANY EXTERNAL STREAM
• EXECUTE ANY EXTERNAL ENDPOINT

Summary of the permission check algorithm

Checking permissions can be complex. The permission check algorithm includes overlapping group memberships and ownership chaining, both explicit and implicit permission, and can be affected by the permissions on securable classes that contain the securable entity. The general process of the algorithm is to collect all the relevant permissions. If no blocking DENY is found, the algorithm searches for a GRANT that provides sufficient access. The algorithm contains three essential elements, the security context, the permission space, and the required permission.

• Security context

  This is the group of principals that contribute permissions to the access check. These are permissions that are related to the current login or user, unless the security context was changed to another login or user by using the EXECUTE AS statement. The security context includes the following principals:

  • The login

  • The user

  • Role memberships

  • Windows group memberships

  • If module signing is being used, any login or user account for the certificate used to sign the module that the user is currently executing, and the associated role memberships of that principal.

• Permission space

  This is the securable entity and any securable classes that contain the securable. For example, a table (a securable entity) is contained by the schema securable class and by the database securable class. Access can be affected by table-, schema-, database-, and server-level permissions. For more information, see Permissions Hierarchy (Database Engine).

• Required permission

  The kind of permission that is required. For example, INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL, and so on.

  Access can require multiple permissions, as in the following examples:

  • A stored procedure can require both EXECUTE permission on the stored procedure and INSERT permission on several tables that are referenced by the stored procedure.

  • A dynamic management view can require both VIEW SERVER STATE and SELECT permission on the view.

General steps of the algorithm

When the algorithm is determining whether to allow access to a securable, the precise steps that it uses can vary, depending on the principals and the securables that are involved. However, the algorithm performs the following general steps:

1. Bypass the permission check if the login is a member of the sysadmin fixed server role or if the user is the dbo user in the current database.

2. Allow access if ownership chaining is applicable and the access check on the object earlier in the chain passed the security check.

3. Aggregate the server-level, database-level, and signed-module identities that are associated with the caller to create the security context.

4. For that security context, collect all the permissions that are granted or denied for the permission space. The permission can be explicitly stated as a GRANT, GRANT WITH GRANT, or DENY; or the permissions can be an implied or covering permission GRANT or DENY. For example, CONTROL permission on a schema implies CONTROL on a table. And CONTROL on a table implies SELECT. Therefore, if CONTROL on the schema was granted, SELECT on the table is granted. If CONTROL was denied on the table, SELECT on the table is denied.

   Note

   A GRANT of a column-level permission overrides a DENY at the object level. You can read more about his here: DENY Object Permissions (Transact-SQL).

5. Identify the required permission.

6. Fail the permission check if the required permission is directly or implicitly denied to any of the identities in the security context for the objects in the permission space.

7. Pass the permission check if the required permission wasn't denied and the required permission contains a GRANT or a GRANT WITH GRANT permission either directly or implicitly to any of the identities in the security context for any object in the permission space.

Special considerations for column level permissions

Column level permissions are granted with the syntax <table_name>(<column _name>). For example:

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

A DENY on the table is overridden by a GRANT on a column. However, a subsequent DENY on the table will remove the column GRANT.

Examples

The examples in this section show how to retrieve permissions information.

A. Return the complete list of grantable permissions

The following statement returns all Database Engine permission by using the fn_builtin_permissions function. For more information, see sys.fn_builtin_permissions (Transact-SQL).

SELECT * FROM fn_builtin_permissions(default);
GO

B. Return the permissions on a particular class of objects

The following example uses fn_builtin_permissions to view all the permissions that are available for a category of securable. The example returns permissions on assemblies.

SELECT * FROM fn_builtin_permissions('assembly');
GO

C. Return the permissions granted to the executing principal on an object

The following example uses fn_my_permissions to return a list of the effective permissions that are held by the calling principal on a specified securable. The example returns permissions on an object named Orders55. For more information, see sys.fn_my_permissions (Transact-SQL).

SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

D. Return the permissions applicable to a specified object

The following example returns permissions applicable to an object called Yttrium. The built-in function OBJECT_ID is used to retrieve the ID of object Yttrium.

SELECT * FROM sys.database_permissions
    WHERE major_id = OBJECT_ID('Yttrium');
GO

Related content

• Permissions Hierarchy (Database Engine)
• sys.database_permissions (Transact-SQL)