GRANT Schema Permissions (Transact-SQL)

Grants permissions on a schema.

Transact-SQL Syntax Conventions

Syntax

GRANT permission  [ ,...n ] ON SCHEMA :: schema_name
    TO database_principal [ ,...n ]
    [ WITH GRANT OPTION ]
    [ AS granting_principal ]

Arguments

• permission
  Specifies a permission that can be granted on a schema. Listed below.

• ON SCHEMA :: schema*_name*
  Specifies the schema on which the permission is being granted. The scope qualifier "::" is required.

• database_principal
  Specifies the principal to which the permission is being granted. One of the following:

  • database user
  • database role
  • application role
  • database user mapped to a Windows login
  • database user mapped to a Windows group
  • database user mapped to a certificate
  • database user mapped to an asymmetric key
  • database user not mapped to a server principal.

• GRANT OPTION
  Indicates that the principal will also be given the ability to grant the specified permission to other principals.

• AS granting_principal
  Specifies a principal from which the principal executing this query derives its right to grant the permission. One of the following:

  • database user
  • database role
  • application role
  • database user mapped to a Windows login
  • database user mapped to a Windows group
  • database user mapped to a certificate
  • database user mapped to an asymmetric key
  • database user not mapped to a server principal.

Remarks

Important

A combination of ALTER and REFERENCE permissions in some cases could allow the grantee to view data or execute unauthorized functions. For example: A user with ALTER permission on a table and REFERENCE permission on a function can create a computed column over a function and have it be executed. In this case the user would also need SELECT permission on the computed column.

A schema is a database-level securable contained by the database that is its parent in the permissions hierarchy. The most specific and limited permissions that can be granted on a schema are listed below, together with the more general permissions that include them by implication.

Schema permission	Implied by schema permission	Implied by database permission
CONTROL	CONTROL	CONTROL
TAKE OWNERSHIP	CONTROL	CONTROL
ALTER	CONTROL	ALTER ANY SCHEMA
EXECUTE	CONTROL	EXECUTE
INSERT	CONTROL	INSERT
DELETE	CONTROL	DELETE
UPDATE	CONTROL	UPDATE
SELECT	CONTROL	SELECT
REFERENCES	CONTROL	REFERENCES
VIEW DEFINITION	CONTROL	VIEW DEFINITION

Warning

A user with ALTER permission on a schema can use ownership chaining to access securables in other schemas, including securables to which that user is explicitly denied access. This is because ownership chaining bypasses permissions checks on referenced objects when they are owned by the principal that owns the objects that refer to them. A user with ALTER permission on a schema can create procedures, synonyms, and views that are owned by the schema's owner. Those objects will have access (via ownership chaining) to information in other schemas owned by the schema's owner. When possible, you should avoid granting ALTER permission on a schema if the schema's owner also owns other schemas.

For example, this issue may occur in the following scenarios. These scenarios assume that a user, referred as U1, has the ALTER permission on the S1 schema. The U1 user is denied to access a table object, referred as T1, in the schema S2. The S1 schema and the S2 schema are owned by the same owner.

The U1 user has the CREATE PROCEDURE permission on the database and the EXECUTE permission on the S1 schema. Therefore, the U1 user can create a stored procedure, and then access the denied object T1 in the stored procedure.

The U1 user has the CREATE SYNONYM permission on the database and the SELECT permission on the S1 schema. Therefore, the U1 user can create a synonym in the S1 schema for the denied object T1, and then access the denied object T1 by using the synonym.

The U1 user has the CREATE VIEW permission on the database and the SELECT permission on the S1 schema. Therefore, the U1 user can create a view in the S1 schema to query data from the denied object T1, and then access the denied object T1 by using the view.

For more information, see the Microsoft KB Article number 914847.

Permissions

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, these additional requirements apply.

AS granting_principal	Additional permission required
Database user	IMPERSONATE permission on the user, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Database user mapped to a Windows login	IMPERSONATE permission on the user, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Database user mapped to a Windows group	Membership in the Windows group, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Database user mapped to a certificate	Membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Database user mapped to an asymmetric key	Membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Database user not mapped to any server principal	IMPERSONATE permission on the user, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Database role	ALTER permission on the role, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.
Application role	ALTER permission on the role, membership in the db_securityadmin fixed database role, membership in the db_owner fixed database role, or membership in the sysadmin fixed server role.

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.

Examples

A. Grant INSERT permission on schema HumanResources to guest.

GRANT INSERT ON SCHEMA :: HumanResources TO guest;

B. Grant SELECT permission on schema Person to database user WilJo.

GRANT SELECT ON SCHEMA :: Person TO WilJo WITH GRANT OPTION;

See Also

Reference

DENY Schema Permissions (Transact-SQL)
REVOKE Schema Permissions (Transact-SQL)
GRANT (Transact-SQL)
CREATE CERTIFICATE (Transact-SQL)
CREATE ASYMMETRIC KEY (Transact-SQL)
CREATE APPLICATION ROLE (Transact-SQL)

Other Resources

Permissions
Principals
Encryption Hierarchy

Help and Information

Getting SQL Server 2005 Assistance