Discussion :

[qi130]

Dans le but de me faire la main sur Oracle je fais 1 appli en Delphi avec dbExpress.

Suite à un post précédent, j'ai défini 1 TS dédié à ma base. Puis j'ai défini 1 schéma, puis les tables dans ce schéma en utilisant le user lié à ce schéma.


Q1: le user lié à ce schéma doit-il recevoir des droits particuliers sur ses propres tables ?

Q2: ayant opté pour un partage de la base par des "comptes" authentifiés par Oracle, j'ai donc:
- défini ces comptes supplémentaire (=schémas vides)
- granté ces comptes sur les tables de la base (select, update, delete,reference)

-> le principe est-il ok ?
-> ces grants sont-ils suffisants ?
-> qui doit granter: SYS ou le "propriétaire" du schéma ?

Q3: pour 1 gestion plus simple, créer un rôle ayant les droits (select, etc...) sur ces tables, puis attribuer ce rôle aux utilisateurs est-il équivalent au principe évoqué à la Q2 ?


Question subsidiaireretour à mon appli)
les tables référencées dans les requètes doivent-elles être préfixées par le schéma qui les abritent ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT .... FROM SCHEMA.LATABLE

en effet, j'ai fait un galop d'essai, sous Delphi, et je ne suis pas "satisfait" du résultat (cf http://www.developpez.net/forums/viewtopic.php?t=426136 pour les patients )

Merci pour votre attention.

[gregory.broissard]

q1 : non. Il doit juste avoir les roles connect et resource

q2: principe ok si tu souhaites fonctionner comme cela.
si tu as des triggers ou des procédures stockées, il faut les granter également. Idem pour les vues.
En principe le Grantor doit toujours etre le propriétaire.

Q3: oui

Q4: par défaut la syntaxe est bien OWNER.LATABLE en SQL Oracle donc si le owner n'est pas renseigné, il cherche une table dans le schéma courant. Si tu veux ne pas être obligé de mettre le owner de la table, il faut que tu créés des synonymes des tables dans chaque schéma.

[Pomalaix]

Bonjour

Mes réponses divergent sur quelques points :

Q1: le user lié à ce schéma doit-il recevoir des droits particuliers sur ses propres tables ?

Si l'utilisateur a au moins CREATE SESSION, CREATE TABLE et un quota sur un tablespace, il peut jouer avec ses tables (CREATE, INSERT, DELETE, UPDATE, SELECT, TRUNCATE, DROP) sans privilèges complémentaires.

Par contre, il lui faudra des privilèges spécifiques pour créer des vues, des séquences, des synonymes, etc.
A noter que ce sont là des privilèges système (c'est à dire généraux) et non des privilèges objets (c'est à dire qui s'appliquent à un objet nommément désigné, tel que la table X).

Ces privilèges complémentaires sont en bonne partie accessibles via les rôles CONNECT et RESOURCE (lesquels se chevauchent partiellement).

Voir cette petite discussion à propos du rôle RESOURCE, dont l'usage est déconseillé en production : http://www.developpez.net/forums/viewtopic.php?t=425488

Q3: pour 1 gestion plus simple, créer un rôle ayant les droits (select, etc...) sur ces tables, puis attribuer ce rôle aux utilisateurs est-il équivalent au principe évoqué à la Q2 ?

Malheureusement, cela n'est pas strictement équivalent.
En particulier, les rôles ne sont pas pris en compte en PL/SQL, et on ne peut pas créer de vue sur des tables sur lesquelles on a obtenu le SELECT via un rôle.

[qi130]

Merci pour vos précieuses réponses à mes interrogations de néophyte

Grâce à vous, mon appli avance:
création des synonymes ("public"), du rôle, grant du rôle sur les tables, attribution du rôle à d'autres comptes.

Je bloque à présent sur un point "curieux" car avec les grants il ne devrait pas se produire (?):

Sur un INSERT des plus classiques, je récupère un "privilèges insuffisants"...

Pourtant, le user connecté a reçu le bon rôle, lequel a bien été granté pour l'insert sur cette table je me perds en conjecture...

[edit]
En fait, cet insert n'est pas si classique que ça puisqu'il met en oeuvre une contrainte de FK

Aussi, y a t'il un grant particulier (references?) à distribuer dans ce contexte ?

[ducho]

bonjour,

une petite confirmation : le grant pour l' insertion
est-il donné par un rôle ou par un privilége ?

l' insert est-il du sql pur ou du pl/sql ?

cdlt

[qi130]

A priori, le user est granté (reçoit) pour le role , et c'est le role qui a été granté pour insert,delete,update et select par le propriétaire du schéma où sont les tables.

Quant à la requète, c'est du SQL pur, encapsulé dans un composant Tquery de dbExpress.
Ceci dit, sous Toad, c'est pareil, par contre, l'update marche... y compris pour la FK

[qi130]

J'ai aussi granté REFERENCES TO PUBLIC, sans résultat

Il y a un truc qui me soucie:

Sous Toad, quand je regarde les droits sur une table de ma base, le role dispose bien des droits attribués, par contre les users qui ont reçu le role ne semblent avoir aucun droit sur cette table...comme si le grant role ne se faisait pas ?