Discussion :

[Clorish]

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 ?

[phoenix38]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
EXECUTE AS LOGIN='toto'
ps_executesql....
REVERT

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

[Clorish]

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é.

[phoenix38]

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.

[Clorish]

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 ....

[phoenix38]

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 ?).