Vues DBA inacessibles pour user SYSTEM depuis une procédure [Résolu]

[scheu]

Je veux créer la procédure suivante (que j'ai simplifiée pour expliquer l'erreur) dans le schéma SYSTEM (je suis connecté en tant que SYSTEM) :

Code :

1
2
3
4
5
 CREATE OR REPLACE PROCEDURE P IS
  CURSOR C IS SELECT * FROM dba_tables;
  BEGIN 
   EXECUTE IMMEDIATE 'SELECT 1 FROM DUAL';
  END;

Et là la compilation sort une erreur ORA-00942: table or view does not exist !
Alors qu'avec une autre vue comme all_tables par exemple ça fonctionne.

Pourtant le user SYSTEM a bien accès en lecture à la vue dba_tables (ça marche depuis une simple requête SQL)

Comment est-ce possible que SYSTEM ait accès à une vue dba depuis du code SQL mais pas du code PL/SQL ? La gestion des droits est-elle différente ? Ou bien aurais-je oublié quelque chose ?

Merci pour votre aide

[orafrance]

Envoyé par scheu

Comment est-ce possible que SYSTEM ait accès à une vue dba depuis du code SQL mais pas du code PL/SQL ? La gestion des droits est-elle différente ?

oui, en PL/SQL, les rôles ne sont pas pris en compte, seulement les privilèges

Par ailleurs, un EXECUTE IMMEDIATE est complétement inutile pour faire du DML sans valeur dynamique

[Michel SALAIS]

Envoyé par orafrance

oui, en PL/SQL, les rôles ne sont pas pris en compte, seulement les privilèges

Une petite précision supplémentaire, ça fonctionne comme ça depuis Oracle 8i.

[scheu]

Merci pour vos réponses j'aurai appris quelque chose
Le EXECUTE IMMEDIATE c'était juste comme exemple, j'avais simplifié le code de ma procédure

[pifor]

Une autre précision: depuis la 8i, on peut également définir une procédure stockée avec la clause AUTHID CURRENT_USER qui signifie qu'elle s'exécute avec les droits de l'utilisateur qui l'exécute (et non avec les droits du propriétaire de la procédure comme c'est le cas par défaut).

Dans ce cas on peut utiliser DBM_SESSION.SET_ROLE pour activer les rôles qui seront pris en compte par le SQL dynamique (et non statique).

Voir les exemples du Security Guide.

Ce n'est sans doute pas d'usage courant mais cela peut parfois être utile.

[Michel SALAIS]

Envoyé par pifor

Ce n'est sans doute pas d'usage courant mais cela peut parfois être utile.

Oui en fait AUTHID CURRENT_USER est utilisé surtout pour partager le code mais pas les données. Plusieurs packages PL/SQL fournis par Oracle utilisent ce modèle.

[scheu]

Envoyé par orafrance

oui, en PL/SQL, les rôles ne sont pas pris en compte, seulement les privilèges

Merci pour ces précisions

Néanmoins, avec du recul j'ai du mal à comprendre pourquoi les rôles ne sont pas pris en compte en PL/SQL ... Quels problèmes de sécurité cela peut-il engendrer ?
Quelqu'un aurait-il un exemple concret ?

[orafrance]

y'a rien à comprendre... c'est comme ça c'est tout