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:
-
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.
-
Allow access if ownership chaining is applicable and the access check on the object earlier in the chain passed the security check. For more information about ownership chaining, see Ownership Chains.
-
Aggregate the server-level, database-level, and signed-module identities that are associated with the caller to create the security context.
-
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. For more information, see Covering/Implied Permissions (Database Engine).
.gif) Note: |
|---|
|
A GRANT of a column-level permission overrides a DENY at the object level.
|
-
Identify the required permission.
-
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.
-
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.