Droits d'execution procedures stockés

La base sur laquelle on travaille interdit aux utilisateur de faire des "Select" sur une table uen fois connecté sous leur login.
Par contre elle autorise l'execution des procedure stockés qui servent d'interface a la base.

Dans une d'entre elle, j'appelle la PS systeme : ps_executesql pour effectuer un select dynamique sur un ensemble de tables.

Cette appel (strictement interne a une de nos procedures stockés) genere une erreur de droits d'acces si la procedure stocké qui l'appelle est executé depuis un compte utilisateur limité.

Peut on affiner les droits pour autoriser l'appel a cette PS si elle est execute en interne d'une procedure stocké a nous ?

Bonjour,
en version 2005, il y a possibilité d'exécuter des procs ou fonctions en tant qu'un autre utilisateur : EXECUTE AS.
Le principe est de créer un user (toto dans l'exemple) avec les droits nécessaires à une action, lui interdire de pouvoir se connecter (pour la sécurité) et lui faire un GRANT IMPERSONATE.
Ensuite, dans la procédure on execute le bout de code en tant que user avec + de droits. Enfin on revient à la normal avec REVERT

Code:

---

1 2 3 4

EXECUTE AS LOGIN='toto' ps_executesql.... REVERT

---

L'aide en ligne l'expliquera certainement mieux que moi.

ok.

ET question cout ? c'est lourd ?

En fait c'est pour executer la PS "ps_executesql" au sein d'un autre PS qui teste la validité d'une valeur transmise avant traitement sur la base.

La selection est interdite aux utilisateurs, or cette procedure execute une select sur des tables, ce qui genere une erreur de gestion des droits.

Le principe : Effectuer un select sur un champs d'un table quelconque dont le nom de la table est transmise en parametre d'une PS.
La solution aurait ete d'utiliser sp_executesql mais le select qu'elle effectue est visiblement bloqué par les regles de gestion des droits mis en place.
Le select sur lestables n'est pas autorisé.

bonjour,
Je ne me suis pas penché sur le problème de coût, mais je ne pense pas que cela soit lourd (dans le principe), il s'agit seulement de dire au moteur d'executer un bloc d'instruction en prenant d'autre droit. Le coût dépendra surtout du select et de la sp_executesql.
Mais, si on affecte des droits particuliers pour un bloc de la procédure, il n'est peut-être plus nécessaire de passer par sp_executesql.

Citation:

---

Envoyé par phoenix38

Mais, si on affecte des droits particuliers pour un bloc de la procédure, il n'est peut-être plus nécessaire de passer par sp_executesql.

---

Ben si :) car a la base je l'utilise pour exectuer du code SQL generique, dont la chaine textuelle est assemblée a partir de parametre transmis a la PS qui l'appelle ....

Citation:

---

Ben si car a la base je l'utilise pour exectuer du code SQL generique, dont la chaine textuelle est assemblée a partir de parametre transmis a la PS qui l'appelle ...

---

Oui, effectivement.
J'avais la même problématique de droits pour restaurer des backups clients pour la hotline et le dev sans que les utilisateurs aient de droits particuliers sur le serveur et cela fonctionne bien avec la méthode execute as.
Mais je n'utilise pas ps_executesql, seulement exec(...), ce qui, a priori, doit faire la même chose (non ?).

Citation:

---

Envoyé par phoenix38

Mais je n'utilise pas ps_executesql, seulement exec(...), ce qui, a priori, doit faire la même chose (non ?).

---

Il parrait :)
J'ai teste cette methode un moment, et ca marche tres bien. Meme que ca me generais les memes erreurs ;)
Par contre, je n'ai jamais reussi a retourner une valeur du code SQL executé, contrairement a sp_executesql

Bonjour,

A partir du moment où tu exécutes du SQL dynamique, les privilèges sont vérifiés sur les objets, et tu sors du contexte de chaînage de propriétaire, tu ne peux pas y couper. C'est une forme de protection contre l'inection SQL. Tu dois donc donner des privilèges de SELECT sur les objets des requêtes dynamiques.

En effet, en 2005, EXECUTE AS permet de mieux gérer ces contraintes. Tu peux déclarer une procédure stockée qui s'exécute avec un contexte précis. Essaie EXECUTE AS OWNER, si tous les objets appartiennent au même schéma que la proc.

ok, je te remercie.

J'ai effectivement vu l'options "EXECUTE AS OWNER" des procedures stockées.
Par coontre je maitrise mal l'influance de "OWNER".

On a actuelement defini un utilisateur virtuel, interdit de connection, possedant les droits d'execution et de select.
On parametre cette procedure comme "EXECUTE AS <Utilisateur virtuel>"

J'ai bien pense a faire une Union de toutes les tables dans une vue qui retourne l'id des tables en colonne 0 et une chaine (nom de la table) etn colonne 1.
Un filtre (clause where) sur le nom de la table (colonne 1) permet de lister uniquement les ID de la table souhaité.
Cette technique marche mais me semble tres lourde a maintenir et surtout a utiliser car elle manipule l'ensemble des ligne de la BdD .....
J'ai peut que question rendement ca court a la catastrophe :(