CONCEDE EXECUTE a todos os procedimentos armazenados

147

O comando a seguir efetivamente concede ao usuário "MyUser" permissão para executar TODOS os procedimentos armazenados no banco de dados?

GRANT EXECUTE TO [MyDomain\MyUser]
sql sql-server tsql sql-server-2008 permissions Chade
fonte

Respostas:

244

SQL Server 2008 e superior:

/* CREATE A NEW ROLE */
CREATE ROLE db_executor

/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor

Para apenas um usuário (não uma função):

USE [DBName]
GO
GRANT EXECUTE TO [user]
Antony Scott
fonte
28
+1 mais: até concede permissões EXECUTE a procedimentos armazenados futuros, por exemplo, aqueles que ainda não estão no seu banco de dados - mas serão criados posteriormente.
21412 Marc
2
Eu acho que vale a pena notar que você userpode estar entre colchetes. Isso era verdade no meu caso de uso, pelo menos em parte porque meu usuário tinha um domínio anexado (ou seja, tinha um caractere \). edit: personagem barra invertida corrigida
PrinceTyke
1
Por que não atribuir o usuário à função db_ddladmin? "Os membros da função de banco de dados fixa db_ddladmin podem executar qualquer comando DDL (Data Definition Language) em um banco de dados." - veja aqui
Michael Tobisch
1
O @MichaelTobisch aqui só precisa executar procedimentos armazenados. A função DDL deve ser usada nos cenários Create, Alter, Drop, .... Esses links devem ser úteis: docs.microsoft.com/en-us/sql/relational-databases/security/… e geeksforgeeks.org/sql-ddl-dml-dcl-tcl-commands
QMaster
2
E o próximo nível de adicionar um usuário a uma função, caso isso salve alguém em outra etapa da pesquisa. ALTER ROLE db_executor ADICIONAR MEMBRO YourUserNameHere
Piwaf
72

O SQL Server 2005 introduziu a capacidade de conceder permissões de execução de banco de dados a um princípio de banco de dados, conforme você descreveu:

GRANT EXECUTE TO [MyDomain\MyUser]

Isso concederá permissão no escopo do banco de dados, que inclui implicitamente todos os procedimentos armazenados em todos os esquemas. Isso significa que você não precisa conceder explicitamente permissões por procedimento armazenado.

Você também pode restringir concedendo permissões de execução de esquema se desejar ser mais granular:

GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
Robin Minto
fonte
5
Ótimo para ser capaz de fazer isso a um esquema específico, evitando assim as permissões em sys
RemarkLima
17

Além das respostas acima, gostaria de adicionar:

Você pode conceder isso a uma função e atribuir a função ao (s) usuário (s). Suponha que você tenha criado uma função myAppRightsvia

CREATE ROLE [myAppRights]

então você pode conceder direitos de execução via

GRANT EXECUTE TO [myAppRights]

para esse papel.

Ou, se você quiser fazer isso no nível do esquema:

GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]

também funciona (neste exemplo, a função myAppRightsterá direitos de execução em todos os elementos do esquema dboposteriormente).

Dessa forma, você só precisa fazer uma vez e pode atribuir / revogar todos os direitos de aplicativos relacionados facilmente para / de um usuário, se precisar alterá-lo posteriormente - especialmente útil se você quiser criar perfis de acesso mais complexos.

Nota: Se você conceder uma função a um esquema, isso também afeta os elementos que você criará posteriormente - isso pode ser benéfico ou não, dependendo do design que você pretendeu, portanto, lembre-se disso.

Matt
fonte
-5

CONCEDE EXECUTAR A [PAPEL]

Este certamente ajuda

Sharon AS
fonte
Você não deseja conceder execução à função pública, ela abre preocupações de segurança. Apenas conceda ao usuário ou função. Conceder execução a procs específicos é o melhor caminho a percorrer, para que você possa controlar quem está acertando o quê.
precisa saber é o seguinte
O sarcasmo aqui não é apropriado para um site de perguntas e respostas, especialmente quando produz resultados possivelmente perigosos.
Christopher Brown
"Todo login pertence à função de servidor público fixo e todo usuário de banco de dados pertence à função de banco de dados público. Quando um login ou usuário não recebe ou nega permissões específicas em um protegível, o login ou usuário herda as permissões concedidas ao público em que pode ser protegido "Portanto, conceder permissões a PUBLIC significa conceder essas permissões a todos os usuários. Esta é uma grande vulnerabilidade. Leia este link para mais informações: docs.microsoft.com/en-us/sql/relational-databases/security/…
QMaster
Com respostas como essa, não é de admirar que haja tantos sites e bancos de dados mal protegidos por aí. Nossa cara.
Dave Lucre