GRANT EXECUTE à toutes les procédures stockées

147

La commande suivante donne-t-elle effectivement à l'utilisateur, «MyUser», l'autorisation d'exécuter TOUTES les procédures stockées dans la base de données?

GRANT EXECUTE TO [MyDomain\MyUser]

— Tchad
source

244

SQL Server 2008 et supérieur:

/* CREATE A NEW ROLE */
CREATE ROLE db_executor

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

Pour juste un utilisateur (pas un rôle):

USE [DBName]
GO
GRANT EXECUTE TO [user]

— Antony Scott
source

28

+1 plus: il accorde même des autorisations EXECUTE aux futures procédures stockées, par exemple celles qui ne sont pas encore dans votre base de données - mais qui seront créées plus tard.

— marc_s

2

Je pense qu'il vaut la peine de noter que vous userdevrez peut-être être entre crochets. C'était vrai dans mon cas d'utilisation au moins en partie parce que mon utilisateur avait un domaine attaché (c'est-à-dire qu'il y avait un caractère \). edit: correction du caractère slash non

— échappé

1

Pourquoi ne pas attribuer à l'utilisateur le rôle db_ddladmin? "Les membres du rôle de base de données fixe db_ddladmin peuvent exécuter n'importe quelle commande DDL (Data Definition Language) dans une base de données." - voir ici

— Michael Tobisch

1

@MichaelTobisch a juste besoin d'exécuter des procédures stockées. Le rôle DDL doit être utilisé dans les scénarios Créer, Modifier, Supprimer, ... Ces liens doivent être utiles: docs.microsoft.com/en-us/sql/relational-databases/security/… et geeksforgeeks.org/sql-ddl-dml-dcl-tcl-commands

— QMaster

2

Et le prochain niveau d'ajout d'un utilisateur à un rôle au cas où cela sauverait quelqu'un une autre étape de recherche. ALTER ROLE db_executor ADD MEMBER YourUserNameHere

— Piwaf

72

SQL Server 2005 a introduit la possibilité d' accorder des autorisations d'exécution de base de données à un principe de base de données, comme vous l'avez décrit:

GRANT EXECUTE TO [MyDomain\MyUser]

Cela accordera une autorisation au niveau de l'étendue de la base de données, qui inclut implicitement toutes les procédures stockées dans tous les schémas. Cela signifie que vous n'êtes pas obligé d'accorder explicitement des autorisations par procédure stockée.

Vous pouvez également restreindre en accordant des autorisations d'exécution de schéma si vous souhaitez être plus précis:

GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]

— Robin Minto
source

5

Génial de pouvoir le faire sur un schéma spécifique, évitant ainsi les autorisations sur sys

— RemarkLima

17

En plus des réponses ci-dessus, j'aimerais ajouter:

Vous souhaiterez peut-être attribuer cela à un rôle à la place, puis attribuer le rôle aux utilisateurs. Supposons que vous ayez créé un rôle myAppRightsvia

CREATE ROLE [myAppRights]

alors vous pouvez donner des droits d'exécution via

GRANT EXECUTE TO [myAppRights]

à ce rôle.

Ou, si vous souhaitez le faire au niveau du schéma:

GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]

fonctionne également (dans cet exemple, le rôle myAppRightsaura des droits d'exécution sur tous les éléments du schéma dbopar la suite).

De cette façon, vous ne devez le faire qu'une seule fois et pouvez facilement attribuer / révoquer tous les droits d'application associés à / d'un utilisateur si vous avez besoin de changer cela plus tard - particulièrement utile si vous souhaitez créer des profils d'accès plus complexes.

Remarque: si vous attribuez un rôle à un schéma, cela affecte également les éléments que vous aurez créés ultérieurement - cela peut être bénéfique ou non en fonction de la conception souhaitée, alors gardez cela à l'esprit.

— Mat
source

-5

GRANT EXECUTE TO [ROLE]

Celui-ci aide sûrement

— Sharon AS
source

Vous ne voulez pas accorder d'exécution au rôle public, cela pose des problèmes de sécurité. Accordez-le simplement à l'utilisateur ou au rôle. Accorder une exécution à des processus spécifiques est la meilleure façon de procéder pour que vous puissiez contrôler qui frappe quoi.

— ammills01

Le sarcasme ici n'est pas approprié pour un site de questions-réponses, en particulier lorsqu'il donne des résultats potentiellement dangereux.

— Christopher Brown

"Chaque connexion appartient au rôle de serveur fixe public et chaque utilisateur de base de données appartient au rôle de base de données publique. Lorsqu'une connexion ou un utilisateur ne s'est pas vu accorder ou refuser des autorisations spécifiques sur un élément sécurisable, la connexion ou l'utilisateur hérite des autorisations accordées à public sur que sécurisable "Donc, accorder des autorisations à PUBLIC, c'est-à-dire accorder ces autorisations à tous les utilisateurs. C'est une grande vulnérabilité. Lisez ce lien pour en savoir plus: docs.microsoft.com/en-us/sql/relational-databases/security/…

— QMaster

Avec des réponses comme celle-ci, il n'est pas étonnant qu'il y ait autant de sites Web et de bases de données mal sécurisés. Geez man.

— Dave Lucre