Proc stock & droits

Bonjour,

J'essaie de créer une procédure dans un schéma SCHEM_1.
Cette procédure fait un select sur une table d'un autre shéma SCHEM_2 :
select col1 into var_col1 from SCHEM_2.MaTable;
Quand je compile cette procédure j'ai comme erreur "PL/SQL: ORA-00942: table or view does not exist".

Ce que je ne comprends pas c'est que quand je suis loggé en SCHEM_1 je peux faire sans problème :
select col1 from SCHEM_2.MaTable

SCHEM_1 a donc les droits pour faire des select sur SCHEM_2 mais pas pour faire des select sur SCHEM_2 dans une procédure stockée ?

Merci de votre aide ?

tu peux nous montrez le code de ta proc ?

attention, en PL/SQL il faut granter le SELECT table par table, les rôles ne sont pas pris en compte (contrairement au SQL)

C'est OK

Merci beaucoup

Plutôt que de créer dans SCHEM_1 une procédure qui accède à des tables de SCHEM_2, il est plus simple de créer une procédure dans SCHEM_2 et de donner le droit d'exécution sur cette procédure à SCHEM_1. Le mieux est même de mettre toutes les procédures d'accès aux données de SCHEM_2 dans des packages de SCHEM_2 puis de donner les droits d'exécutions sur ces packages aux autres users qui en ont besoin.

Ainsi les autres users n'ont besoin d'aucun droit sur les tables, vues... de SCHEM_2, seulement le droit d'exécution sur les packages. C'est beaucoup plus simple comme gestion de droits et beaucoup plus sécurisé car les users autres que SCHEM_2 ne pourront effectuer sur les données de SCHEM_2 que ce qui est autorisé dans les procédures stockées.

C'est le modèle que nous appliquons :

- Un schéma unique schema1, propriétaire des tables, vues...
- Des users applicatifs qui n'ont que les droits suivants :
. grant create session to app_u_1;
. grant execute on schema1.pkg_1 to app_u_1;

Chacun de ces users applicatifs a le droit d'exécution sur 1 package en général, parfois 2 ou 3. Un user applicatif correspond à une application, par exemple "gestion des connexions utilisateurs", "Requêtes client de catégorie n"...

Le schéma unique n'est pas une obligation, on peut imaginer des regroupements fonctionnels de tables et des clés étrangères inter-schémas, mais le principe est le même : ne jamais utiliser un user qui a plus de droits que nécessaire dans une application.

Cordialement,

rbaraer