Précédent   Forum des professionnels en informatique > Bases de données > Oracle > Administration
Administration Forum d'entraide sur l'administration du serveur Oracle
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 04/03/2011, 18h21   #1
Membre confirmé
 
Avatar de awalter1
 
Inscription : août 2004
Messages : 665
Détails du profil
Informations forums :
Inscription : août 2004
Messages : 665
Points : 232
Points : 232
Par défaut méthode de création de ma base

Bonjour,
J'ai une base de données oracle 10g. Mon application utilise un compte oracle OPS$OPE pour toutes les créations d'objets, puis il y a un compte par utilisateur user0, user1 .... Chaque user doit pouvoir accèder aux tables applicatives.
La procédure pour créer mes tables applicatives est la suivante :
Code :
1
2
3
4
5
6
7
8
connect ops$ope/...@mabase
CREATE TABLE TEST ...
GRANT SELECT, INSERT, UPDATE, DELETE ON TEST TO user0;
commit;
connect user0/...@mabase
DROP synonym TEST;
CREATE OR REPLACE synonym TEST FOR ops$ope.TEST;
commit;
Est ce que cette façon de faire est correcte ?
Qu'apporterait après la création de chaque table l'instruction :
Code :
GRANT SELECT, INSERT, UPDATE, DELETE ON TEST TO PUBLIC
Merci
awalter1 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 05/03/2011, 21h35   #2
Membre éprouvé
 
Femme
Administrateur de base de données
Inscription : novembre 2007
Messages : 341
Détails du profil
Informations personnelles :
Sexe : Femme
Localisation : France

Informations professionnelles :
Activité : Administrateur de base de données

Informations forums :
Inscription : novembre 2007
Messages : 341
Points : 478
Points : 478
bonjour,

le commit c'est après la création de la table.
le synonym, c'est le propriétaire (donc pendant la connection ops$ope) qui doit le créer pour les autres users (ou bien sys), ce qui leur évitera de préfixer la table pendant leurs propres opérations. Ce qui est important ce sont les droits donnés sur l'objet.
De manière générale, j'éviterais de donner des droits à PUBLIC, c'est une faille de sécurité parce que n'importe quel user pourra opérer des modifications sur ton objet, mais en admettant que ce soit l'effet recherché, si jamais tu changes d'avis sur les privileges accordés et que tu revoques un privilege qui a été alloué à PUBLIC sur un objet alors tous les objets qui font référence à ce dernier deviennent invalides et doivent être ré-autorisés.
pour faciliter l'administration, s'il y a beaucoup de users applicatifs, c'est plus facile de créer un rôle et de donner les droits sur chaque table à ce rôle puis granter ce rôle aux users applicatifs. La base de données est faite pour administrer des groupes, des users qui ont des droits différents
Heaven93 est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 15h58.


 
 
 
 
Partenaires

Hébergement Web