Permissions (Database Engine)

Every SQL Server securable has associated permissions that can be granted to a principal. This topic provides the following information:

• Permissions naming conventions

• Permissions related to specific securables

• SQL Server permissions

• Permission check algorithm

• Examples

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

For a poster sized chart of all Database Engine permissions in pdf format, see https://go.microsoft.com/fwlink/?LinkId=229142.

Permissions Applicable to Specific Securables

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

SQL Server Permissions

The following table provides a complete list of SQL Server permissions.

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.

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 was not 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.

Examples

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

A. Returning the complete list of grantable permissions

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

SELECT * FROM fn_builtin_permissions(default);
GO

B. Returning 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. Returning 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, seesys.fn_my_permissions (Transact-SQL).

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

D. Returning the permissions applicable to a specified object

The following example returns permissions applicable to an object called Yttrium. Notice that 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

See Also

Reference

sys.database_permissions (Transact-SQL)

Concepts

Permissions Hierarchy (Database Engine)