DENY Object Permissions (Transact-SQL)

 

Updated: June 10, 2016

THIS TOPIC APPLIES TO:yesSQL Server (starting with 2008)yesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Denies permissions on a member of the OBJECT class of securables. These are the members of the OBJECT class: tables, views, table-valued functions, stored procedures, extended stored procedures, scalar functions, aggregate functions, service queues, and synonyms.

Topic link icon Transact-SQL Syntax Conventions

  
DENY <permission> [ ,...n ] ON   
    [ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ]  
        TO <database_principal> [ ,...n ]   
    [ CASCADE ]  
        [ 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  

permission
Specifies a permission that can be denied on a schema-contained object. For a list of the permissions, see the Remarks section later in this topic.

ALL
Denying ALL does not deny all possible permissions. Denying ALL is equivalent to denying all ANSI-92 permissions applicable to the specified object. The meaning of ALL varies as follows:

Scalar function permissions: EXECUTE, REFERENCES.

Table-valued function permissions: DELETE, INSERT, REFERENCES, SELECT, UPDATE.

Stored Procedure permissions: EXECUTE.

Table permissions: DELETE, INSERT, REFERENCES, SELECT, UPDATE.

View permissions: DELETE, INSERT, REFERENCES, SELECT, UPDATE.

PRIVILEGES
Included for ANSI-92 compliance. Does not change the behavior of ALL.

column
Specifies the name of a column in a table, view, or table-valued function on which the permission is being denied. The parentheses ( ) are required. Only SELECT, REFERENCES, and UPDATE permissions can be denied on a column. column can be specified in the permissions clause or after the securable name.

System_CAPS_ICON_caution.jpg Caution


A table-level DENY does not take precedence over a column-level GRANT. This inconsistency in the permissions hierarchy has been preserved for backward compatibility.

ON [ OBJECT :: ] [ schema_name ] . object_name
Specifies the object on which the permission is being denied. The OBJECT phrase is optional if schema_name is specified. If the OBJECT phrase is used, the scope qualifier (::) is required. If schema_name is not specified, the default schema is used. If schema_name is specified, the schema scope qualifier (.) is required.

TO <database_principal>
Specifies the principal to which the permission is being denied.

CASCADE
Indicates that the permission being denied is also denied to other principals to which it has been granted by this principal.

AS <database_principal>
Specifies a principal from which the principal executing this query derives its right to deny the permission.

Database_user
Specifies a database user.

Database_role
Specifies a database role.

Application_role
Specifies an application role.

Database_user_mapped_to_Windows_User
Specifies a database user mapped to a Windows user.

Database_user_mapped_to_Windows_Group
Specifies a database user mapped to a Windows group.

Database_user_mapped_to_certificate
Specifies a database user mapped to a certificate.

Database_user_mapped_to_asymmetric_key
Specifies a database user mapped to an asymmetric key.

Database_user_with_no_login
Specifies a database user with no corresponding server-level principal.

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 denied on an object are listed in the following table, together with the more general permissions that include them by implication.

Object permissionImplied by object permissionImplied by schema permission
ALTERCONTROLALTER
CONTROLCONTROLCONTROL
DELETECONTROLDELETE
EXECUTECONTROLEXECUTE
INSERTCONTROLINSERT
RECEIVECONTROLCONTROL
REFERENCESCONTROLREFERENCES
SELECTRECEIVESELECT
TAKE OWNERSHIPCONTROLCONTROL
UPDATECONTROLUPDATE
VIEW CHANGE TRACKINGCONTROLVIEW CHANGE TRACKING
VIEW DEFINITIONCONTROLVIEW DEFINITION

Requires CONTROL permission on the object.

If you use the AS clause, the specified principal must own the object on which permissions are being denied.

A. Denying SELECT permission on a table

The following example denies SELECT permission to the user RosaQdM on the table Person.Address in the AdventureWorks2012 database.

USE AdventureWorks2012;  
DENY SELECT ON OBJECT::Person.Address TO RosaQdM;  
GO  

B. Denying EXECUTE permission on a stored procedure

The following example denies EXECUTE permission on the stored procedure HumanResources.uspUpdateEmployeeHireInfo to an application role called Recruiting11.

USE AdventureWorks2012;  
DENY EXECUTE ON OBJECT::HumanResources.uspUpdateEmployeeHireInfo  
    TO Recruiting11;  
GO   

C. Denying REFERENCES permission on a view with CASCADE

The following example denies REFERENCES permission on the column BusinessEntityID in the view HumanResources.vEmployee to the user Wanida with CASCADE.

USE AdventureWorks2012;  
DENY REFERENCES (BusinessEntityID) ON OBJECT::HumanResources.vEmployee   
    TO Wanida CASCADE;  
GO  

GRANT Object Permissions (Transact-SQL)
REVOKE Object Permissions (Transact-SQL)
Object Catalog Views (Transact-SQL)
Permissions (Database Engine)
Principals (Database Engine)
Securables
sys.fn_builtin_permissions (Transact-SQL)
HAS_PERMS_BY_NAME (Transact-SQL)
sys.fn_my_permissions (Transact-SQL)

Community Additions

ADD
Show: