Discussion :

[lepierot]

Bonjour est il possible de creer un utilisateur Oracle avecun 'acces en lecture sur un seul schema ?

Merci

[vanagreg]

Bonjour,

Quelle est ta version d'Oracle?
Il n'existe pas de privilège "read only" sur tout un schéma pour la création d'un user, il faut que tu octroies les droits sur chaque objet du schéma à ce user. En général on crée un rôle à qui on donne ces privilèges puis on donne le rôle au user concerné.
A partir de la version 12.1 il vaut mieux attribuer le privilège READ que SELECT, car ce dernier laisse la possibilité de locker la table en ajoutant la clause FOR UPDATE.

[lepierot]

Bonjour, je suis en version 11.2.0.4.
Merci pour ta réponse.

[Ikebukuro]

Impossible à faire, il faudra que tu génères un fichier .sql listant tous les GRANTs que tu veux donner aux objets du schéma.
Par exemple :

Code :

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

SELECT 'GRANT SELECT ON ' || table_name || ' TO USER2;' FROM DBA_TABLES WHERE owner = 'user1';

Là où c'est corsé c'est qu'il faudra que tu traites les différents droits (SELECT, UPDATE, INSERT, DELETE, INDEX, REFERENCES...) mais aussi les différents types d'objets (TABLE, VUE, SEQUENCE...) sachant que tel droit n'a pas de sens pour tel objet

Je te conseille de chercher du code sur le ne, à moins que le contenu de ton schéma soit très simple.

[lepierot]

Pour une version d'Oracle supérieure cela aurait il été plus simple ?

[Ikebukuro]

Pas à ma connaissance.

[SQLpro]

C'est une des grosses lacunes d'Oracle. Tous les autres SGBDR pratiquent la sécurisation au niveau des schémas ou des bases.
Tu doit donc passer par un script listant un a un les tables ET LES VUES....
Mais le problème c'est que dès qu'une vue ou une table sera rajoutée au schéma, il faudra penser à lui rajouter ces privilèges !

A +

[PaulNero]

Bonjour,
It is possible avec plsql.
1- create l'utilisateur

>

CREATE USER toto
IDENTIFIED BY toto
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;

2- create le role

create role p_role ;

3-give le grant aux objects du schema

>

BEGIN
FOR j IN (SELECT * FROM dba_tables WHERE owner='schema_name')
LOOP
EXECUTE IMMEDIATE 'GRANT SELECT ON schema_name.' || j.table_name ||
' TO ro_role';
END LOOP;
END;

4-give le role à user

grant p_role to toto;

Vous peut aussi faire plus simple as this:

create user toto identified by toto; grant create session, select any table, select any dictionary to toto;

la session qui applique ces commandes est la session du schema visé.

[pachot]

Mais le problème c'est que dès qu'une vue ou une table sera rajoutée au schéma, il faudra penser à lui rajouter ces privilèges !

C'est justement pour cette raison que ce n'est pas implémenté je pense: éviter que qqn crée une table et l'expose à quelqu'un d'autre sans le savoir (= sans le faire explicitement). I suffit de faire un DDL trigger si c'est le comportement souhaité:
https://blog.psftdba.com/2009/03/automatically-granting-privileges-on.html

[SQLpro]

Excuse moi, mais là tu te contredis de façon assez amusante ! je te cite :
1) c'est par sécurité que c'est interdit....
2) ... on peut le faire en codant un déclencheur DDL
Question : le fait de la faire par un déclencheur DDL c'est aussi par sécurité que c'est permis !!!!



A +

[vanagreg]

L'utilisation d'un trigger DDL n'est pas courante pour ce genre de pratiques. Et d'ailleurs la création d'un tel trigger est elle même soumise à privilège, c'est donc un DBA qui créera ce trigger si besoin. Si ton appli est bien faite tu n'en as pas besoin, car les grants nécessaires seront faits au moment de la création de la table.

[pachot]

Question : le fait de la faire par un déclencheur DDL c'est aussi par sécurité que c'est permis !!!!

La sécurité ce n'est pas de permettre ou d'interdire, mais d'attribuer une responsabilité.

Avec la déclaration d'un grant schema, à qui est attribuée la responsabilité si une donnée critique est visible? Celui qui a fait le grant schema? Non car il ne sait pas quelle table va être créée par la suite. Celui qui a créé la table? Non il n'a pas fait le grant.

Si tu fais le code procédural du trigger, la sécurité deviens ta responsabilité: tu peux filtrer, loguer, auditer,... S'il y a une fuite de donnée, c'est ton code qui en est responsable.

[pachot]

L'utilisation d'un trigger DDL n'est pas courante pour ce genre de pratiques. Et d'ailleurs la création d'un tel trigger est elle même soumise à privilège, c'est donc un DBA qui créera ce trigger si besoin. Si ton appli est bien faite tu n'en as pas besoin, car les grants nécessaires seront faits au moment de la création de la table.

Exactement. C'est celui qui crée la table qui définit sa visibilité. Le grant doit se trouver en source control avec le create table.