Cláusula EXECUTE AS (Transact-SQL)

Sintaxe

Functions (except inline table-valued functions), Stored Procedures, and DML Triggers
{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' } 

DDL Triggers with Database Scope
{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' } 

DDL Triggers with Server Scope and logon triggers
{ EXEC | EXECUTE } AS { CALLER | SELF | 'login_name' } 

Queues
{ EXEC | EXECUTE } AS { SELF | OWNER | 'user_name' } 

Argumentos

• CALLER
  Especifica que as instruções do módulo são executadas no contexto do chamador do módulo. O usuário executando o módulo deve ter permissões apropriadas não apenas no módulo em si, mas também em qualquer objeto que seja referenciado pelo módulo.

  CALLER é o padrão para todos os módulos, exceto filas, e tem o mesmo comportamento que no SQL Server 2005.

  CALLER não pode ser especificado em uma instrução CREATE QUEUE ou ALTER QUEUE.

• SELF
  EXECUTE AS SELF equivale a EXECUTE AS user_name, onde o usuário especificado é a pessoa que cria ou altera o módulo. A ID de usuário real da pessoa que cria ou modifica os módulos é armazenada na coluna execute_as_principal_id da exibição do catálogo sys.sql_modules ou sys.service_queues.

  SELF é o padrão para filas.

  Observação
  Para alterar a ID de usuário de execute_as_principal_id da exibição do catálogo sys.service_queues, é necessário especificar a configuração EXECUTE AS na instrução ALTER QUEUE.

• OWNER
  Especifica que as instruções do módulo são executadas no contexto do proprietário atual do módulo. Se o módulo não tiver um proprietário especificado, o proprietário do esquema do módulo será usado. OWNER não pode ser especificado para gatilhos DDL ou de logon.

  Importante
  OWNER deve mapear a uma conta singleton e não deve ser uma função ou grupo.

• 'user_name'
  Especifica que as instruções dentro do módulo sejam executadas no contexto do usuário especificado em user_name. As permissões para qualquer objeto no módulo são verificadas em user_name. user_name não pode ser especificado para gatilhos DLL com escopo de servidor ou gatilhos de logon. Em vez disso, use login_name .

  user_name deve existir no banco de dados atual e deve ser uma conta singleton. user_name não pode ser um grupo, uma função, um certificado, uma chave ou conta interna, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService ou NT AUTHORITY\LocalSystem.

  A ID de usuário do contexto de execução é armazenada em metadados e pode ser exibida na coluna execute_as_principal_id da exibição do catálogo sys.sql_modules ou sys.assembly_modules.

• 'login_name'
  Especifica que as instruções do módulo devem ser executadas no contexto do logon do SQL Server especificado em login_name. As permissões para qualquer objeto no módulo são verificadas em login_name. login_name pode ser especificado somente para gatilhos DLL com escopo de servidor ou gatilhos de logon.

  login_name não pode ser um grupo, uma função, um certificado, uma chave ou conta interna, como NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService ou NT AUTHORITY\LocalSystem.

Comentários

A forma como o Mecanismo de Banco de Dados avalia as permissões nos objetos que são referenciados no módulo depende da cadeia de propriedade que existente entre os objetos de chamada e os objetos referenciados. Nas versões anteriores do SQL Server, a cadeia de propriedade era o único método disponível para não ter de conceder ao usuário chamador acesso a todos os objetos referenciados.

A cadeia de propriedade tem as seguintes limitações:

• Só se aplica a instruções DML: SELECT, INSERT, UPDATE e DELETE.

• Os proprietários da chamada e os objetos chamados devem ser os mesmos.

• Não se aplica a consultas dinâmicas no módulo.

Para obter mais informações sobre encadeamento de propriedades, consulte Cadeias de propriedade.

Independentemente do contexto de execução especificado no módulo, as seguintes ações sempre se aplicam:

• Quando o módulo é executado, o Mecanismo de Banco de Dados primeiro verifica se o usuário executando o módulo tem a permissão EXECUTE no módulo.

• As regras de cadeia de propriedade continuam aplicáveis. Isso significa que, se os proprietários dos objetos chamadores e chamados são os mesmos, nenhuma permissão é verificada nos objetos subjacentes.

Quando um usuário executa um módulo que foi especificado para ser executado em um contexto diferente de CALLER, a permissão do usuário para executar o módulo é verificada, mas as verificações de permissões adicionais nos objetos que são acessados pelo módulo são executadas na conta de usuário especificada na cláusula EXECUTE AS. O usuário que executa o módulo está, na verdade, representando o usuário especificado.

O contexto especificado na cláusula EXECUTE AS do módulo é válido somente para a duração da execução do módulo. O contexto é revertido ao chamador quando a execução de módulo é concluída. Para obter mais informações sobre como alternar o contexto de execução em um módulo, consulte Usando EXECUTE AS em módulos.

Especificando um nome de logon ou usuário

Um usuário de banco de dados ou logon de servidor especificado na cláusula EXECUTE AS de um módulo não pode ser descartado até que o módulo seja modificado para ser executado em outro contexto.

O nome de usuário ou de logon especificado na cláusula EXECUTE AS deve existir como um principal em sys.database_principals ou sys.server_principals, respectivamente, caso contrário a operação de criar ou alterar o módulo falhará. Além disso, o usuário que cria ou altera o módulo deve ter as permissões IMPERSONATE no principal.

Se o usuário tiver acesso implícito ao banco de dados ou à instância do SQL Server através de uma associação de grupo do Windows, o usuário especificado na cláusula EXECUTE AS será criado implicitamente quando o modulo for criado, caso um dos seguintes requisitos exista:

• O usuário ou logon especificado é um membro da função de servidor fixa sysadmin.

• O usuário que está criando o módulo tem permissão para criar os principais.

Quando nenhum desses requisitos é atendido, a operação de criar o módulo falha.

Importante
Se o serviço do SQL Server (MSSQLSERVER) for executado em uma conta local (serviço local ou conta de usuário local), ele não terá privilégios para obter associações de grupo de uma conta de domínio do Windows que for especificada na cláusula EXECUTE AS. Isso fará a execução do módulo falhar.

Por exemplo, considere as seguintes condições:

• O grupo CompanyDomain\SQLUsers tem acesso ao banco de dados Vendas.

• CompanyDomain\SqlUser1 é um membro de SQLUsers e, por isso, tem acesso ao banco de dados Vendas .

• O usuário que está criando ou está alterando o módulo tem permissões para criar os principais.

Quando a seguinte instrução CREATE PROCEDURE é executada, o CompanyDomain\SqlUser1 é implicitamente criado como um principal de banco de dados no banco de dados Sales.

USE Sales;
GO
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT user_name();
GO

Usando a instrução autônoma EXECUTE AS CALLER

CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'SqlUser1'
AS
SELECT user_name(); -- Shows execution context is set to SqlUser1.
EXECUTE AS CALLER;
SELECT user_name(); -- Shows execution context is set to SqlUser2, the caller of the module.
REVERT;
SELECT user_name(); -- Shows execution context is set to SqlUser1.
GO

Usando EXECUTE AS para definir conjuntos de permissões personalizadas

Prática recomendada

Permissões

Para executar um módulo especificado com EXECUTE AS, o chamador precisar ter permissões EXECUTE no módulo.

Para executar um módulo CLR especificado com EXECUTE AS que acesse recursos em outro banco de dados ou servidor, o banco de dados ou servidor de destino deve confiar no autenticador do banco de dados do qual o módulo origina (o banco de dados de origem). Para obter mais informações sobre como estabelecer confiança de autenticador, consulte Estendendo representação de banco de dados com EXECUTE AS.

Para especificar a cláusula EXECUTE AS ao criar ou modificar um módulo, é necessário ter as permissões IMPERSONATE no principal especificado e também permissões para criar o módulo. Você sempre pode se representar. Quando nenhum contexto de execução é especificado ou EXECUTE AS CALLER é especificado, as permissões de IMPERSONATE não são solicitadas.

Para especificar um login_name ou user_name que tenha acesso implícito ao banco de dados através de uma associação de grupo do Windows, é necessário ter permissões CONTROL no banco de dados.

Exemplos

O exemplo a seguir cria um procedimento armazenado e atribui o contexto de execução a OWNER.

USE AdventureWorks;
GO
CREATE PROCEDURE HumanResources.uspEmployeesInDepartment 
@DeptValue int
WITH EXECUTE AS OWNER
AS
    SET NOCOUNT ON;
    SELECT e.EmployeeID, c.LastName, c.FirstName, e.Title
    FROM Person.Contact AS c 
    INNER JOIN HumanResources.Employee AS e
        ON c.ContactID = e.ContactID
    INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
        ON e.EmployeeID = edh.EmployeeID
    WHERE edh.DepartmentID = @DeptValue
    ORDER BY c.LastName, c.FirstName;
GO

-- Execute the stored procedure by specifying department 5.
EXECUTE HumanResources.uspEmployeesInDepartment 5;
GO

Consulte também

Referência

Conceitos