Procédure stockée et Autorisations - la commande d'EXÉCUTION Est assez?
J'ai un Serveur SQL server 2008 de la base de données où tous les accès aux tables sous-jacentes est fait par le biais de procédures stockées. Certaines procédures stockées simplement SÉLECTIONNER des enregistrements dans les tables, tandis que d'autres UPDATE, INSERT et DELETE.
Si une procédure stockée MISES à jour d'un tableau est l'utilisateur qui exécute la procédure stockée également besoin de mettre à JOUR les autorisations pour les tables concernées ou est le fait qu'ils ont des autorisations d'EXÉCUTION de la procédure stockée assez?
Fondamentalement, je me demandais si en donnant à l'utilisateur les autorisations d'EXÉCUTION de la procédure stockée est suffisant ou dois-je leur donner SELECT, UPDATE, DELETE et INSERT, d'autorisations pour les tables dans l'ordre pour les procédures stockées de travail. Merci.
[MODIFIER] Dans la plupart de mes procédures stockées, il ne semble en effet que l'EXÉCUTION est assez. Cependant, je n'ai trouver que des procédures stockées où "Exécuter sp_Executesql" a été utilisé pour EXÉCUTER n'était pas assez. Les tables impliquées nécessaire d'avoir les autorisations pour les actions effectuées au sein de "sp_Executesql".
- J'ai peur que lors de l'utilisation de requêtes SQL, vous devez accorder des autorisations sur l'objet sous-jacent. J'ai mis à jour la réponse à refléter.
- Vous êtes correct. J'ai trouvé que j'avais besoin pour permettre datareader l'accès aux tables pour les utilisateurs. Heureusement, ce n'était pas un problème pour ma situation étant donné que tous les utilisateurs ont été autorisés à afficher toutes les données.
- Dans une autre réponse, @RemusRusanu des liens vers une alternative: 1) la création d'un certificat; 2) Créer un utilisateur associé à ce certificat; 3) Accorder à l'utilisateur des droits appropriés [aux ressources protégées]; et 4) de Signer la procédure stockée avec le certificat, chaque fois que vous modifiez la procédure stockée (stackoverflow.com/a/4081604/6894566 de les relier à d' : sommarskog.se/grantperm.html#Certificats ). Signature ajoute le certificat de droits d'utilisateur pour l'utilisateur actuel jeton, qui SQL Server conserve lors de l'appel de procédures du système et le SQL dynamique invoquée par EXEC() ou sp_executesql. Si la procédure stockée réussit.
Vous devez vous connecter pour publier un commentaire.
Les autorisations d'exécution de la procédure stockée est suffisant.
Puis la (non-db_owner) utilisateur a les droits suivants:
Toutefois, si le SQL dynamique à l'intérieur de dbo.SPTemp qui tente de les insérer dans la dbo.Temp, alors ce sera l'échec. Dans ce cas, l'autorisation directe sur le tableau devra être accordée.
Autorisations sur les tables ne sont pas vérifiées (y compris les NIER) si les tables et les proc ont le même propriétaire. Ils peuvent être dans différents schémas trop aussi longtemps que les schémas ont le même propriétaire.
Voir Le chaînage de propriété sur MSDN
Modifier, à partir d'un commentaire de l'un supprimée réponse.
Le contexte est toujours en cours de connexion, à moins que
EXECUTE AS
a été utilisée: seul objet référencé DML autorisations ne sont pas vérifiées. Essayez OBJECT_ID(referencedtable) dans une procédure stockée, où aucun droits sont cédés à referencedtable. Il donne la valeur NULL. Si elle est exécutée par le propriétaire de la procédure stockée ensuite, il serait de donner une valeur à cause owener a des droits sur referencedtableOBJECT_ID
de l'indice a été très utile; j'avais besoin d'un moyen de vérifier si un utilisateur est en mesure d'exécuter une procédure stockée, cela a fonctionné à merveillePeut-être que vous pouvez utiliser
lorsque vous créez une procédure stockée, comme ci-dessous:
Alors vous n'avez qu'à permettre à l'utilisateur
EXECUTE
l'autorisation de la procédure stockéeXXX
.Autorisation d'exécuter une procédure stockée qui exécute une instruction insert, update, ou delete est suffisante. Vous n'avez pas besoin d'accorder des autorisations au niveau de la table. En fait, je ne conseille pas cette approche. À l'aide d'une procédure stockée, vous donne plus de contrôle sur la façon dont le changement se produit. Par exemple, vous souhaitez peut-être faire quelques vérifications avant d'autoriser la mise à jour. À l'aide d'une procédure stockée peut aussi aider à prévenir les accidents majeurs-comme la suppression de toutes les lignes dans la table parce que quelqu'un a oublié la clause where!
MERCI BEAUCOUP! J'ai eu un problème similaire. Cela me conduire à la réponse.
J'ai été de tenter de trunctate une table dans une procédure stockée qui appelle d'autres procédures stockées qui ont été imbriqués dans les instructions if.
Mon erreur a été
Le serveur principal "domaine\mon_id" n'est pas en mesure d'accéder à la base de données "2nd_DB" sous le contexte de sécurité actuel.
J'avais donné l'appel de la procédure stockée droits à faire de tronquer (EXÉCUTER en tant QUE AUTO), qui a causé un problème, parce que l'AUTO n'a pas de droits à la 2e DB. Notre solution est de déplacer la tronquer à une autre SP, comprennent l'EXÉCUTER en tant QUE SOI. Nous appelons aujourd'hui le tronquer SP, exécuter notre traitement des données, faire de la logique de la détermination, et appeler le 3e SP.