Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

Accès en lecture à un seul schéma


Sujet :

Administration Oracle

  1. #1
    Nouveau membre du Club
    Accès en lecture à un seul schéma
    Bonjour est il possible de creer un utilisateur Oracle avecun 'acces en lecture sur un seul schema ?

    Merci

  2. #2
    Membre éprouvé
    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.

  3. #3
    Nouveau membre du Club
    Bonjour, je suis en version 11.2.0.4.
    Merci pour ta réponse.

  4. #4
    Membre chevronné
    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.
    DBA Oracle
    Rédacteur du blog : dbaoraclesql.canalblog.com

  5. #5
    Nouveau membre du Club
    Pour une version d'Oracle supérieure cela aurait il été plus simple ?

  6. #6
    Membre chevronné
    Pas à ma connaissance.
    DBA Oracle
    Rédacteur du blog : dbaoraclesql.canalblog.com

  7. #7
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  8. #8
    Membre confirmé
    read only on schema
    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é.
    Cordialement,
    J'ose espérer que m'a contribution vous a été d'une grande aide.
    Pensez tout de Même à dire MERCI et marquer RESOLU en cas de satisfaction.
    Paul

  9. #9
    Expert éminent
    Citation Envoyé par SQLpro Voir le message

    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
    Franck Pachot - dbi services - Consulting et Formation en Suisse et remote - fpa@dbi-services.com
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  10. #10
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  11. #11
    Membre éprouvé
    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.

  12. #12
    Expert éminent
    Citation Envoyé par SQLpro Voir le message
    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.
    Franck Pachot - dbi services - Consulting et Formation en Suisse et remote - fpa@dbi-services.com
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  13. #13
    Expert éminent
    Citation Envoyé par vanagreg Voir le message
    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.
    Franck Pachot - dbi services - Consulting et Formation en Suisse et remote - fpa@dbi-services.com
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

###raw>template_hook.ano_emploi###