Privilége refusé dans procédure stockée

Bonjour,

J'ai un utilisateur "Jean" qui n'a pas le droit de faire le SELECT directement sur la table T_ENGINE".
J'ai une procédure stockée dynamique qui fait un SELECT sur une table "T_ENGINE".
Mon utilisateur "Jean" a donc bien le droit d'exécuter la procédure.
L'utilisateur qui a crée la table et la procédure est l'utilisateur dbo.

Mon problème est donc que lors de l’exécution de la procédure j'ai un message d'erreur: L'autorisation SELECT a été refusée sur l'objet 'T_ENGINE', base de données 'TEST', schéma 'dbo'.

Je ne comprends pas pourquoi SQL vérifie si l'utilisateur Jean a bien le privilège SELECT sur la table "T_ENGINE"

Aurez vous une idée

Merci par avance

Je viens d'essayer en modifiant ma procédure sans que celle ci exécute du sql dynamique et cela fonctionne.
Le problème vient donc du fait que ma requête est générer dynamiquement:

Code:

---

1 2 3

SET @SQLStatement = 'SELECT '+rtrim(@TABLE_NAME)+'_'+rtrim(@VARIABLE_NAME)+'.NAME FROM '+rtrim(@TABLE_NAME)+'_'+rtrim(@VARIABLE_NAME)   EXECUTE sp_executesql @SQLStatement

---

Je ne vois pas pourquoi cela ne fonctionne pas...

Bonjour,

En effet, avec un EXECUTE, la requête est exécutée dans un contexte différent. Ainsi la chaine de confiance n'est plus valide, c'est comme si l'utilisateur appelant la procédure stockée faisait une requête adhoc : les privilèges sont vérifiés.

Je pense que vous pouvez obtenir le comportement que vous souhaitez en créant la procédure comme ceci

Code:

---

1 2 3 4 5 6 7

CREATE PROCEDURE LaPRocedure WITH EXECUTE AS OWNER AS BEGIN ... END

---

Ainsi le EXECUTE sera exécuté dans le contexte du créateur de la procédure stockée.
Mais... attention à ce que vous faites dans votre procédure stockée et à qui vous accordez les privilèges d’exécution...

Enfin, d'après les deux lignes de code que vous avez postées, j'ai l'impression que vous avez un problème de modélisation... mais c'est un autre sujet, et il faudrait mieux connaitre votre contexte pour en dire plus...

Merci de votre réponse cela fonctionne
Tous les utilisateurs de ma base on le privilège d’exécution de cette procédure...

Pour la modélisation j'ai:

Une table
T_ENGINE : ID int(PK) ,NAME varchar(50),COURBE int (FK sur ID de T_ENGINE_COURBE)

T_ENGINE_COURBE: ID int (PK),NAME varchar(50)
Cette table référence tous les noms de courbe de la variable COURBE


T_ENGINE_COURBE_DATA : ID int (FK sur ID de T_ENGINE_COURBE) ,X float,Yfloat
Cette table contient les points de chaque courbe

Si je veux voir tous les noms de courbe du paramètre COURBE j'utilise:

Code:

---

SELECT T_ENGINE_COURBE.NAME FROM T_ENGINE_COURBE

---

SI je veux récupérer tous les points d'une courbe

Code:

---

1 2	SELECT * FROM T_ENGINE_COURBE_DATA WHERE ID=(Id de ma courbe)

---

En réalité j'ai une variable COURBE1,2,3,4,5,6,7.... qui ont leur table T_ENGINE_COURBE1,T_ENGINE_COURBE2..... et la table T_ENGINE_COURBE1_DATA...... associé

J'ai le même type de variable courbe dans d'autres tables c'est pour cela que j'utilise ma procédure stocké qui est crée dynamiquement. Cela me permet d'avoir une seule procédure pour récupérer mes noms de courbe mais cela n'est peut être pas la bonne manière de faire en terme de sécurité?

Non en effet, vous devriez plutôt n'avoir qu'une table T_ENGINE_COURBE contenant une colonne pour différencier courbe1 de courbe2...

J'ai oublié de préciser que mes courbes n'ont pas forcement le même nombres d'axes donc directement pas le même nombres de colonnes.
Je peux donc avoir une table T_ENGINE_COURBE qui stocke tous les noms de me courbes avec une colonne qui me permet de réaliser un filtrage entre courbe1,2,3....
Mais il est plus simple pour moi de stocker les points de courbe1,2,3.... dans différentes tables DATA ayantpour nom de colonne les noms des axes.

Je pourrais donc faire une relation d'héritage avec exclusion mutuelle sur l'ID T_ENGINE_COURBE avec ID de mes tables DATA?

A mon avis, vous devez poser votre probleme dans un forum de conception comme merise,uml...

Ok merci de vos réponses