Version imprimable
Bonjour à tous,
je me pose des questions sur la façon d'accorder les privilèges select, insert, update, delete sur les tables et les vues d'un schéma.
Je ne trouve à priori que les grant sur des tables. Y a-t-il une syntaxe particulière ?
merci à tous
Non, Oracle ne sait pas faire !
Il faut les "granter" une à une !
A +
Bonjour,
Les privilèges se donnent au niveau de chaque object, mais il est facile de le faire pour toutes les tables:
Cordialement,Code:exec for i in (select table_name from user_tables) loop execute immediate 'grant select,insert,update,delete on '||i.table_name||' to xxx'; end loop
Franck.
Bonjour et merci pour le retour.
Donc, pour accorder les droits "select,insert,update,delete" d'un utilisateur que j'ai créé en base sur un autre schéma il faut que je me positionne dans le schéma souhaité (alter session set current_schema=nom_schéma;) et que je passe la ligne de commande ?
Merci d'avance
Oui. Ca peut être customisé. Em lisant ALL_TABLES (+ critère sur OWNER) si on ne veut pas être connecté avec ce user. Avec ALL_VIEWS pour faire la même chose sur les vues, etc.
C'est pour cette raison qu'il n'y a pas une syntaxe SQL. Normalement, on ne fait pas des grants pour tous les objets. Par exemple, si on accède aux tables via des vues, le but est de granter les vues, pas les tables.
Le problème est que ce ne sera pas dynamique. Par exemple si quelqu'un créé une nouvelle table ou vue dans le schéma, les privilèges ne seront pas accordés.
Une solution serait de jouer sur les déclencheurs DDL et lors d'un CREATE TABLE ou CREATE VIEW y ajouter les privilèges adéquats.
Questions aux experts Oracle (dont je ne suis pas) :
1) une commande DDL est-elle possible dans un déclencheur DDL Oracle ?
2) en cas de ROLLBACK le déclencheur DDL Oracle annule t-il l'accord de privilège ?
3) comment se fait-il qu'Oracle soit toujours en retard sur ces sujets aussi primordiaux que l'accord de privilèges au niveau schéma ? Cela se fait sous SQL Server depuis 2005 et sous PostGreSQL...
A +
Je ne pense pas qu'Oracle implémentera ça un jour, pour des raisons de sécurité. Granter de manière automatique toute nouvelle table d'un utilisateur sans savoir ce que contiendra cette table n'est pas une bonne idée. Lorsqu'on donne un privilège, il faut un responsable pour cette accréditation. Dans ce cas, qui serait le responsable? Celui qui a granté avant qu'il y ait la table? Ou celui qui a créé la table sans savoir qu'il y avait un grant automatique? Par analogie: Je peux donner procuration sur mes comptes bancaires, un par uns. Mais aucune banque (j'espère) n'offre la possibilité de donner automatiquement procuration sur tous les comptes futurs ouverts par un client.Citation:
Envoyé par SQLpro
Bien sûr on pourrait faire un trigger. Mais je ne vois pas trop pourquoi. L'ajout d'une table se fait par un script de déploiement, qui ne fait probablement pas que créer la table. Pourquoi ne pas intégrer les grants nécessaires à ce script, tout simplement?
Normalement en Oracle on ne crée pas des tables dynamiquement dans l'application. L'exception notable ça sera un script d'installation d'une application, sinon nul besoin et la faire et c'est plutôt un signe d'une mauvaise habitude de programmation.Citation:
Envoyé par SQLpro
Pour le reste celui qui crée la table doit prendre soin de donner les privilèges nécessaires. Les scripts comme celui suggéré par pachot répondent généralement à une évolution de l'application plutôt qu'a une installation normale.
Les triggers DDL ne permettrons pas de la faire directement. En fait la commande DDL est exécutée conceptuellement de la manière suivante:Citation:
Envoyé par SQLpro
Pour accorder des privilèges il faut que l'objet existe or il n'existe pas encore ni dans le trigger before (create) ni dans celui after (create)!Code:
2
3
4
Par contre il est possible dans le trigger de publier l'événement a une liste des applications abonnées qui pourront utiliser cette information (creation de la table TABLE) comme bon leur semble.