Início / dba / Perguntas / 174184
Accepted
Anil
Asked: 2017-05-22 23:38:04 +0800 CST

GRANT EXECUTE ON SomeProc TO SomeRole AS dbo

  • 772

Eu tenho uma função ExecSPque uso para gerenciar quem pode executar procedimentos armazenados. EXECUTEpermissão é concedida em todos os SPs para esta função.

Também uso o SQL Server Data Tools (SSDT) ​​para gerenciar o esquema de banco de dados do MS SQL Server. No arquivo onde meu SP está definido, tenho isso:

CREATE PROC SomeProc AS
.
.
.

GO

GRANT EXECUTE ON SomeProc TO ExecSP

No entanto, quando aplico a alteração no banco de dados de destino e faço a comparação do esquema, ele relata diferenças nas permissões do SP, onde no lado do banco de dados tenho isso:

GRANT EXECUTE ON SomeProc TO ExecSP AS dbo

Já tentei entender qual AS dboparte representa, mas não consegui.

Minhas perguntas:

  1. Significa que o SP será executado com dbodireitos, independentemente de quem o estiver executando? (Eu acho/espero que não.)
  2. Por que isso é adicionado automaticamente?
  3. Eu quero que este SP seja executado com os direitos que o chamador tem - como faço para conseguir isso?
sql-server stored-procedures

2 respostas

    1. De BOL:

    Use a cláusula AS principal para indicar que o principal registrado como o concedente da permissão deve ser um principal diferente da pessoa que executa a instrução. Por exemplo, suponha que o usuário Mary seja o principal_id 12 e o usuário Raul seja o principal 15. Mary executa GRANT SELECT ON OBJECT::X TO Steven WITH GRANT OPTION AS Raul; Agora a tabela sys.database_permissions indicará que o grantor_prinicpal_id era 15 (Raul) mesmo que a instrução tenha sido realmente executada pelo usuário 13 (Mary).

    https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-transact-sql

    Portanto, neste caso, o mecanismo está gravando o concedente como dbo, em vez da conta que executa o código real.

    1. Não tenho certeza por que isso seria - talvez devido a algum aspecto da comparação de esquema, dbo é usado para garantir que não haja registros órfãos em termos do concedente? Talvez outra pessoa possa dar uma luz.

    2. Ele deve fazer isso de qualquer maneira - você quer dizer, neste caso, o chamador é a função ExecSP ou o próprio usuário? De qualquer forma, isso já deve estar acontecendo, se você atribuiu a função ou não.

    • 2
  2. Best Answer

    Use a cláusula AS principal para indicar que o principal registrado como o concedente da permissão deve ser um principal diferente da pessoa que executa a instrução. Por exemplo, suponha que o usuário Mary seja o principal_id 12 e o usuário Raul seja o principal 15. Mary executa GRANT SELECT ON OBJECT::X TO Steven WITH GRANT OPTION AS Raul; Agora a tabela sys.database_permissions indicará que o grantor_prinicpal_id era 15 (Raul) mesmo que a instrução tenha sido realmente executada pelo usuário 13 (Mary).

    Isso esta errado. Tente reproduzi-lo e você receberá o erro:

    Msg 15151, Level 16, State 1, Line 1 Não é possível localizar o objeto 'X' porque ele não existe ou você não tem permissão.

    Mesmo que Mary e Raul sejam membros da função de servidor fixa sysadmin. E é por isso: a cláusula AS não se destina a ser usada com WITH GRANT OPTION, mas, como diz a versão offline do BOL 2008R2:

    AS principal Especifica um principal do qual o principal que executa esta consulta obtém seu direito de conceder a permissão

    Ou seja, o repro mencionado acima com Mary e Raul ambos sysadmins falha porque Raul não tem permissão explícita no objeto X, e mesmo que não seja necessário conceder uma permissão explícita sendo sysadmin, desta vez recebemos um erro porque a verificação de permissão não é ignorado: o servidor verifica o sys.database_permissions para localizar a permissão apropriada.

    A cláusula AS é usada no seguinte cenário: temos uma função de banco de dados MyRole que recebe alguma permissão WITH GRANT OPTION. Vamos Mary ser um usuário-membro do MyRole. Agora Mary quer dar a permissão que ela tem para Steven, mas o simples

    GRANT SELECT ON OBJECT::X TO Steven

    falhou porque como um simples usuário Mary não tem permissão no X, mas se ela escreve

    GRANT SELECT ON OBJECT::X TO Steven como MyRole

    funciona bem: há a concessão explícita para MyRole é sys.database_permissions

    Voltando à sua pergunta, se você tentar agora fazer o script de qualquer objeto usando o Management Studio (banco de dados -> tarefas -> gerar scripts, selecionar alguns objetos e em "avançado" ativar "permissões de nível de objeto de script"), você obterá o mesmo script: GRANT ... AS DBO. E somente no caso com o papel você verá GRANT .. AS MYROLE. Portanto, o Studio sempre cria scripts para o concedente de sys.database_permissions, mas não é uma "auditoria", você nunca verá outros principais que não sejam dbo, exceto para o caso de função, e mesmo se você tiver um principal que tenha apenas a permissão CONTROL em apenas um objeto, quando ele conceder permissão a alguém para aquele objeto, em sys.database_permissions o concedente será dbo.

    • 2

relate perguntas