v$datafile doit être declaré

Mouais... m'enfin, j'en viens toujours à la même conclusion... si tu veux créer un rôle qui te donne des droits sur une liste fermée de table... bah ça marche pas en PL/SQL... donc pour la sécurité c'est pas super puisque le contournement c'est soit SELECT ANY TABLE (donc plus exaustif) soit GRANT TABLE sur tous les utilisateurs eu risque d'oublier des droits en cas de création d'une nouvelle table en plus d'être pénible si tu as beaucoup de tables :?

Le seul intérêt c'est que ça fait une question facile à répondre pour les gentils DBA que nous sommes :mrgreen:

Non, ça me semble tout à fait sain comme fonctionnement

Soit tu veux granter le privilège de select à un compte applicatif lambda, et là, l'utilisation du rôle est nickel et pour tes 5000 utilisateurs applicatifs, tu n'auras qu'un seul rôle à définir.
Super simple, rapide, facile et sûr.

Mais si tu veux rajouter un autre module applicatif (un programme qui va posséder des objets, des tables, des PACKAGES, ...), là, c'est une autre paire de manche.
Ton module applicatif peut voir les données, mais tu n'as pas forcément envie qu'il s'amuse à "attaquer" tes tables en PL/SQL pour y bidouiller.
Donc, tu dois expressément dire ce que tu veux bien qu'il fasse en programmation.

Là où c'est moins pratique, c'est si ton compte applicatif lambda doit créer des objets
mais ça me semble une faute de conception car bonjour si tes comptes applicatifs doivent se créer chacun des vues, packages, ...

Citation:

---

Envoyé par LeoAnderson

Ton module applicatif peut voir les données, mais tu n'as pas forcément envie qu'il s'amuse à "attaquer" tes tables en PL/SQL pour y bidouiller.
Donc, tu dois expressément dire ce que tu veux bien qu'il fasse en programmation.

---

Tu veux dire un cas où ça ne te dérange pas que les users voient les données en SQL mais pas en PL/SQL ? T'as déjà eu affaire à ce type de besoin pour me donner un exemple ?

Désolé, j'ai le cerveau englué aujourd'hui mais décidément, j'vois pas en quoi obliger le DBA a donné des privilèges au lieu d'un seul rôle aux utilisateurs est plus sécuritaire :(

Citation:

---

Envoyé par orafrance

Tu veux dire un cas où ça ne te dérange pas que les users voient les données en SQL mais pas en PL/SQL ? T'as déjà eu affaire à ce type de besoin pour me donner un exemple ?

Désolé, j'ai le cerveau englué aujourd'hui mais décidément, j'vois pas en quoi obliger le DBA a donné des privilèges au lieu d'un seul rôle aux utilisateurs est plus sécuritaire :(

---

par exemple une appli de gestion des heures (destinée à des dév. Oracle)
au lieu de passer par le serveur Web ad'hoc (avec les contraintes, les mails envoyés par l'appli, ..), certains se sont amusé à faire une moulinette PL/SQL d'insertion (via utl_file_dir)
Les droits en PL/SQL doivent alors être différents des droits SQL

Citation:

---

Envoyé par orafrance

c'est soit SELECT ANY TABLE (donc plus exaustif) soit GRANT TABLE sur tous les utilisateurs

---

Non, pas sur tous les utilisateurs, seulement sur ceux qui créent des procédures ou des vues...

certes, tous les users = tout ceux qui auraient eu le role ;)

oui, c'est vrai, dans le cas de cette discussion, le role DBA n'est pas suffisant comme mentionné, alors que SELECT ANY DICTIONARY est OK