Logique ou pas logique ? Telle est la question

Bonjour à tous,

Un développeur rencontre un problème très étrange...

Il crée une procédure avec l'utilisateur TOTO dans le shéma de TOTO.

Dans sa procédure il réalise des traitements, crée un directory, donne les droits à public (READ et WRITE), puis veux créer sa table externe tout ca en SQL dynamique (execute immediate). Pour information les ordres sont tous corrects !

Le problème rencontré se trouve au niveau du :

Code:

---

EXECUTE IMMEDIATE 'CREATE TABLE... ORGANIZATION EXTERNAL...'

---

Oracle lui retourne l'erreur droits insuffisant. De ce fait on a testé dans une fenêtre SQL*Plus hors de la procédure et le code marche, la table externe est créée et on y accède normalement.

Donc on retourne dans notre procédure, on regarde le propriétaire les droits etc... tous est correct, TOTO a sa procédure stockée dans son schéma, la table doit être crée dans son schéma avec les bons droits.

Du coup, je me suis dis tentons le AUTHID CURRENT_USER et là, ca marche...

Incompréhensible... TOTO lance une procédure qui lui appartient qui crée un objet dans son schéma et on est obligé de lui dire de le faire avec ses droits.

Est-ce un bug ?

Oracle 10g

Non ce n'est pas un bug et sensé fonctionner ainsi au moins à partir d'Oracle 8i pour le propriétaire de la procédure et depuis Oracle 7 pour les autres ...

Le point clé est l'acquisition des droits à travers des rôles sachant que les rôles ne sont pas utilisables lors de l'exécution des traitements stockés créés avec la clause "authid definer"

Les rôles peuvent bien être activés dans du PL/SQL stocké avec la clause AUTHID CURRENT_USER et l'utilisation de EXECUTE IMMEDIATE si on utilise le DBMS_SESSION.SET_ROLE d'après le Security Guide.

Si je comprends bien, je crée une procedure comme cela dans le schéma TOTO :

Code:

---

1 2 3

CREATE OR REPLACE PROCEDURE test is .... execute immediate 'CREATE TABLE .... ' END;

---

La table créée le sera dans le schéma TOTO.

Mon utilisateur TOTO possède juste le rôle dev (sans parler des privilèges et rôles de connection). Le rôle dev a comme privilège : CREATE TABLE, ALTER TABLE, etc...

Si TOTO lance la procédure test, celle-ci va s'exécuter mais SANS prendre en compte le rôle de dev ? Et pour qu'il active le rôle, je dois l'activer avec la clause AUTHID CURRENT_USER (j'ai pas encore regardé le DBMS_SESSION.SET_ROLE) ?

Par contre si mon utilisateur TOTO possède DIRECTEMENT le privilège CREATE TABLE et qu'il lance la procédure qui ne contient pas le AUTHID CURRENT_USER, celle-ci fonctionnera et la table sera créée.

Est-ce bien cela ?

Citation:

---

Envoyé par Milo59000

Du coup, je me suis dis tentons le AUTHID CURRENT_USER et là, ca marche...

---

Mff, ça m'inquiète de lire des choses comme ça, et ça me fait penser à ceux qui bricolent avec les transactions autonomes en croyant faussement que ça résoudra leur problème de table en mutation !

Dans un cas comme dans l'autre, il s'agit de ne pas se focaliser sur un effet secondaire arrangeant, en oubliant l'effet principal de la technique, qui lui a de fortes chances d'être fonctionnellement inadapté ou indésirable.

La vocation du mode AUTHID CURRENT_USER est de permettre la mise en commun d'une procédure que l'on veut pouvoir faire tourner sur plusieurs schémas différents, possédant un même jeu de tables.
En effet, une procédure AUTHID CURRENT_USER sera exécutée avec les droits de celui qui l'appelle, et les objets manipulés par la procédure seront recherchés dans le schéma de l'exécutant (et non dans le schéma du propriétaire de la procédure comme c'est le cas par défaut).

Le fait que les rôles soient activés en mode CURRENT_USER n'est qu'un effet secondaire, et il ne doit en aucun cas justifier à lui seul l'usage de ce mode.

Si l'accès aux données se fait exclusivement sous le nom du propriétaire des objets (on se connecte comme TOTO pour manipuler les objets de TOTO), l'usage injustifié du CURRENT_USER peut passer inaperçu et donner momentanément satisfaction. (Il provoquerait une légère dégradation des performances, dont je ne connais pas l'ampleur.)
Mais le mode CURRENT_USER constituera un véritable champ de mines, si d'aventure les accès se font par un compte distinct de celui du propriétaire des objets.