web-dev-qa-db-fra.com

Procédure stockée et autorisations - EXECUTE est-il suffisant?

J'ai une base de données SQL Server 2008 où tous les accès aux tables sous-jacentes se font par le biais de procédures stockées. Certaines procédures stockées se bornent à SÉLECTIONNER les enregistrements des tables tandis que d’autres UPDATE, INSERT et DELETE. 

Si une procédure stockée met à jour une table, l'utilisateur qui l'exécute a-t-il également besoin d'autorisations UPDATE sur les tables affectées ou le fait qu'il dispose d'autorisations d'exécution sur la procédure stockée est-il suffisant? 

En gros, je me demande si le fait de donner à l'utilisateur des autorisations EXECUTE sur les procédures stockées est suffisant ou dois-je lui donner les autorisations SELECT, UPDATE, DELETE et INSERT sur les tables pour que les procédures stockées fonctionnent. Je vous remercie.

[EDIT] Dans la plupart de mes procédures stockées, il semble en effet qu'EXECUTE est suffisant. Cependant, j'ai constaté que dans les procédures stockées où "Execute sp_Executesql" était utilisé, EXECUTE n'était pas suffisant. Les tables impliquées devaient disposer d'autorisations pour les actions en cours d'exécution dans "sp_Executesql".

sql-serverstored-procedurespermissions
34
webworm

L'exécution d'autorisations sur la procédure stockée est suffisante.

CREATE TABLE dbo.Temp(n int)

GO
DENY INSERT ON dbo.Temp TO <your role>
GO
CREATE PROCEDURE dbo.SPTemp(@Int int)
AS

INSERT dbo.Temp
SELECT  @Int 

GO

GRANT EXEC ON dbo.SPTemp TO <your role>

GO

Ensuite, l'utilisateur (non-propriétaire_db) aura les droits suivants:

EXEC dbo.SPTemp 10
GO

INSERT dbo.Temp --INSERT permission was denied on the object 'Temp'
SELECT  10

Cependant, si dbo.SPTemp contient un SQL dynamique qui tente de l'insérer dans dbo.Temp, cela échouera. Dans ce cas, une autorisation directe sur la table devra être accordée.

12
Noel Abrahams

Les autorisations sur les tables ne sont pas vérifiées (y compris DENY) si les tables et proc ont le même propriétaire. Ils peuvent également figurer dans des schémas différents, à condition qu'ils aient le même propriétaire.

See Chaînage des propriétés sur MSDN

Modifier, à partir d'un commentaire d'une réponse supprimée.

Le contexte est toujours l'identifiant actuel sauf si EXECUTE AS a été utilisé: seules les autorisations DML des objets référencés ne sont pas vérifiées. Essayez OBJECT_ID (table référencée) dans un processus stocké où aucun droit n'est attribué à la table référencée. Cela donne NULL. S'il est exécuté par le propriétaire du proc stocké, il donnera une valeur car owener a des droits sur la table référencée.

24
gbn

Peut-être que vous pouvez utiliser 

"avec execute en tant que propriétaire"

lorsque vous créez la procédure stockée, telle que ci-dessous:

create procedure XXX
with execute as owner
as
begin
...
end
go

Ensuite, vous devez uniquement accorder à l'utilisateur l'autorisation EXECUTE pour la procédure stockée XXX.

3
yuan liu

L'exécution d'une autorisation sur une procédure stockée qui effectue une insertion, une mise à jour ou une suppression est suffisante. Vous n'avez pas besoin d'accorder ces autorisations au niveau de la table. En fait, je découragerais cette approche. L'utilisation d'une procédure stockée vous permet de mieux contrôler la manière dont le changement se produit. Par exemple, vous voudrez peut-être vérifier avant d'autoriser la mise à jour. L'utilisation d'une procédure stockée peut également aider à prévenir les accidents majeurs - comme la suppression de toutes les lignes du tableau, car quelqu'un a oublié la clause WHERE!

2
Bryan Cooper

MERCI SO BEAUCOUP! J'avais un problème similaire. Cela m'a amené à la réponse.

J'essayais de ponctuer une table dans une procédure stockée qui appelait d'autres procédures stockées imbriquées dans des instructions IF.

Mon erreur était 

Le principal du serveur "domaine\mon_id" n'est pas en mesure d'accéder à la base de données "2nd_DB" dans le contexte de sécurité actuel.

J'avais donné à l'appelant les droits de procédure stockée pour effectuer la troncature (EXECUTE AS SELF), ce qui posait alors un problème, car SELF n'avait pas de droits sur le 2nd DB. Notre solution consistait à déplacer le tronqué vers un autre SP, y compris EXECUTE AS SELF. Nous appelons maintenant le SP tronqué, exécutons notre traitement de données, effectuons une détermination logique et appelons le 3ème SP approprié.

1
ARLibertarian