————————————————–
– une vue de BLAKE sur une table de SCOTT
————————————————–
connect scott
(scott a les droits sur la table)
create view vscott as select * from emp

connect blake
select * from scott.vscott
*
ERROR at line 1:
ORA-00942: table or view does not exist

connect scott
grant select on emp to blake

…le droit sur la table sert pour accéder …a la table
connect blake
select * from scott.vscott
*
ERROR at line 1:
ORA-00942: table or view does not exist

…Le droit sur la vue suffit
connect scott
grant select on vscott to blake

connect blake
select * from scott.vscott
–> OK

———————————————————
—KING accede a une vue de BLAKE sur une table de SCOTT
———————————————————
connect SYSTEM
grant select on scott.emp to blake;
create view blake.vblake as select * from scott.emp
connect SYSTEM
SQL> grant select on blake.vblake to king;
Autorisation de privilèges (GRANT) acceptée.
connect KING
select * from blake.vblake
*
ERROR at line 1:
ORA-01031: insufficient privileges

Si on avait tenté de donner les droits en tant que BLAKE
cela aurait été plus clair :
connect blake
grant select on blake.vblake to king
*
ERROR at line 1:
ORA-01720: grant option does not exist for ‘SCOTT.EMP’

LA SOLUTION
connect SCOTT (ou SYSTEM)
grant select on scott.emp to blake WITH GRANT OPTION

Pour des raisons de sécurité évidentes, un utilisateur autre que DBA n’a aucun droit a priori….même pas celui de se connecter ? la base de données !

Droits implicites

Par contre, le créateur d’un objet (TABLE, VUE , INDEX, etc.) est son propriétaire,et a implicitement des droits sur cet objet. Il possède tous les droits sur son contenu : consultation, mises ? jour, mais aussi suppression complète de sa structure (le contenant).

– exemple

– on suppose que l’utilisateur DD a reçu le droit de se connecter et de creer des tables…
SQL> connect DD/DD
SQL> create table essai (n integer);
Table created
– droit d’insertion (mais aussi suppression et modification) implicite
SQL> insert into essai values (1);
1 ligne créée.
SQL> commit;
Validation effectuée.
– a fortiori droit de consultation
SQL> select * from essai;
N
———-
1
– suppression de la table et de son contenu
SQL> drop table essai;
Table supprimée.Par contre un autre utilisateur (s’il n’est pas DBA) n’a a priori aucun droit sur les tables des autres:

– exemple

– on suppose que DD possede une table T1…
SQL> connect toto/toto
SQL> select * from dd.t1;
select * from dd.t1
*
ERREUR ? la ligne 1 :
ORA-00942: table or view does not exist

Droits explicites - GRANT et REVOKE

GRANT et REVOKE permettent respectivement de donner ou de supprimer les droits explicites d’accès en lecture ou

mise ? jour ? un utilisateur particulier, pour un objet particulier.
C’est en général le propriétaire de l’objet peut donner des droits d’accès ? un autrer utilisateur.

– exemples:

SQL> GRANT SELECT ON TAB_CLIENTS TO MARTIN
SQL> GRANT UPDATE, INSERT ON TAB_CLIENTS TO DUPONTpar défaut un DBA ne peut pas donner des droits d’accès ? un objet qui ne lui appartient pas. Le propriétaire doit lui céder les drois avec un grant option (!?) :

SQL> connect system/xxxx
Connected.
SQL> grant select on intranet.annuaire to scott;
ERROR at line 1: ORA-01031: insufficient privilegesLe type de privilège dépend évidemment de l’objet sur lequel il s’applique. Ceci est résumé ici :

SELECT (uniquement !) -> les séquences

SELECT, INSERT, UPDATE, DELETE -> les tables, les vues, les vues matérialisées

REFERENCE (possibilité de créer une clé étrangère sur la table) -> les tables et les vues

EXECUTE -> les procédures

INDEX, ON COMMIT REFRESH, QUERY REWRITE -> les tables

Il est possible de donner un privilège avec le droit de transférer ce privilège ? d’autres (? utiliser avec parcimonie). Ceci se fait avec l’otion ‘GRANT’ du GRANT (!) :GRANT SELECT ON TAB_CLIENTS TO DUPONT WITH GRANT OPTION
(on suppose que TAB_CLIENTS est un synonyme public visible par tout le monde). Dupont, même s’il n’est pas propriétaire pourra alors ? son tour faire :
GRANT SELECT ON TAB_CLIENTS TO MARTIN

une erreur très répandue consiste ? référencer un objet (dont on n’est pas proprétaire et sur lequel il n’y pas de synonyme) par son nom, SANS le préfixer par le nom du propriétaire. exemple : SELECT * from EMP au lieu de

SELECT * FROM SCOTT.EMP
ceci donne une erreur d’accès du type

ERROR at line 1:
ORA-00942: table or view does not exist (?!)

même si on a les droits de lecture…

DBA et droits Oracle (privilèges et roles)

Un utilisateur Oracle (déclaré au sein de la base, ? distinguer de l’utilisateur au niveau OS) peut être DBA.
Il a tous les ‘privilèges système’ AU SEIN DE LA BASE, et le droit de les transmettre (ADMIN OPTION)
Grace ? quoi, il peut essentiellement :
* consulter et mettre ? jour (SELECT, UPDATE, INSERT, DELETE) toutes les données utilisateur de la base
* créer, modifier des structures de données utilisateur (CREATE, ALTER, DROP) n’importe ou (ANY TABLESPACE)
* gérer des utilisateurs et des droits (CREATE/DROP USER, GRANT, REVOKE)
* consulter la totalité du dictionnaire
* exécuter des ordres d’administration purs (CREATE DATABASE, DATAFILE, TABLESPACE)

Il y a 2 utilisateurs privilégiés prédéfinis, SYS et SYSTEM (dont les mots de passe sont définis ? la création de la base ou par ‘ORAPWD’)
Ils sont tous les 2 DBA, mais SYS est plus privilégié en ce sens qu’il est propriétaire des tables et vues du dictionnaire.

Il existe un ensemble de privilège (ROLE) prédéfini nommé ‘DBA’ qui donne les privilèges nécessaire ? un DBA.
Après avoir créé un utilisateur ‘normal’ il suffit de lui donner ce rôle pour en faire un DBA :
SQL> GRANT DBA TO

note : Il existe un autre rôle prédéfini, parmi quelques dizaines, qui est également intéressant c’est le role ‘SELECT_CATALOG_ROLE’. Il est souvent utilisé par des progiciels ou applicatifs utilisant Oracle pour récupérer des méta données.

Privilèges d’exploitation (SYSDBA et SYSOPER)

Certains ‘administrateurs’ : les opérateurs et techniciens d’exploitation, ou ‘exploitants’ pour faire court, n’ont pas forcément besoin d’un niveau de privilège DBA.

Les opérations concernés sont par exemple :

* les démarrage / arrêts,

* les sauvegardes / restaurations,

* la planification et l’exécution de batch

Oracle fournit 2 niveaux de privilèges, qui peuvent être assimilés ? des niveuax de connexion, qui satisfont ces besoins : les privilèges d’exploitation ‘SYSDBA’ et ‘SYSOPER’.
Comme tout accès privilégié il s’acquiert via un processus d’identification / authentification.

Authentification locale au niveau du système d’explotation

C’est une forme d’authentification externe, en ce sens que ce n’est pas Oracle qui contrôle la connexion grace ? son référentiel interne. On se connecte directement (via telnet ou ssh par exemple) au système qui héberge le serveur de données, puis ? la base locale, sans plus faire intervenir le réseau.
Ce type de connexion originale ne nécessite pas d’identifiant ni de mot de passe Oracle, mais d’être un utilisateur privilégié au niveau O.S.

note : un utilisateur quelconque, non privilégié de la base, peut aussi être défini avec une authentificatin externe, et se connecter localement avec une commande du type : sqlplus /

On peut dire que dans ce cas la sécrité est déportée au niveau O.S. et qu’Oracle accorde sa ‘confiance’ aux mécanismes d’identification / authentification de ce dernier.

exemples de connexion avec le client SQL standard :
connexion ‘normale’
$sqlplus scott/tiger
connexion avec authentification externe
$sqlplus / as sysdba
$sqlplus / as sysoper

Pour obtenir un ‘privilège’ d’exploitation il suffit d’appartenir au groupe utilsateur correspondant au niveau système :

privilège  gpe unix    groupe windows
SYSDBA     dba         ORA_DBA
SYSOPER    oper        ORA_OPER

Ces groupes sont créés lors de l’installation, et un administrateur système en ‘hérite’ automatiquement

note : Le ‘CONNECT INTERNAL’ des versions précédentes est définitivement obsolète et a été remplacé par le ‘CONNECT SYS AS SYSDBA. Parallèlement il n’est plus possible de se connecter SYS ‘tout court’ sans préciser ‘AS SYSDBA’.

Authentification distante au niveau du système d’explotation

Elle présente les mêmes caratéristiques que précédemment saus que la base est située sur une machine distate de la connexion système courante.

La syntaxe de connexion devient donc :
$ sqlplus /@nom_base_distante AS SYSDBA (ou SYSOPER)

Un paramètre d’initialisation de la base : REMOTE_OS_AUTJENTICATION=TRUE autorise cette fonctionnalité.

Note importante : il est vivement conseillé pour des raisons de sécurité d’invalité cette possibilité.

Authentification via fichier de mots de passe
Dans ce cas de figure, les privilèges seront controlés ? partir d’un fichier de mot de passe cryptés local.
exemple de création du fichier :
$ ORAPWD FILE=monfic PASSWORD=monpasse ENTRIES=100
avec
PASSWORD : le mot de passe de SYS
ENTRIES : le nb mas d’utilisateurs référencables dans le fichier.

on peut ensuite créer un utilisateur TOTO avec mot de passe TUTU et que le DBA lui donne le privilège oracle (et non pas système cette fois) nécessaire : SYSDBA ou SYSOPER :

$> sqlplus / AS SYSDBA
SQL> CREATE USER TOTO IDENTIFIED BY TUTU;
SQL> GRANT CREATE SESSION TO TOTO (qu’il aie le droit de se connecter quand même…)
$ GRANT SYSDBA TO TOTO (et lui donner le privilège d’exploitation qui va bien)

note : le paramètre d’initialisation REMOTE_LOGIN_PASSWORDFILE doit être ? EXCLUSIVE (c’est le défaut) pour pouvoir utiliser et modifier le password file

DBA et droits niveau OS (système d’exploitation)

La fonction de DBA, nécessite des privilèges au niveau Système d’exploitation :
- pour l’installation,
- la maintenance,
- la gestion et l’execution de batchs, de scripts (SQL ou shell),
- les sauvegardes / restauration

Sur Unix / Linux :
Il existe un user Unix nommé ‘oracle’ et un groupe associé nommé ‘dba’.
Tous les fichiers Oracle, appartiennent ? ‘utilisateur Oracle.

On peut (doit ?) crééer autant d’utilisateur Unix que de DBAs dans l’entreprise ; dba1, dba2, appartenant au groupe ‘dba’.Ceci permet d’éviter les recouvrements et d’avoir une meilleure tracabilité.
On évitera de travailler connecté en tant qu’utilisateur ‘oracle’ pour éviter toute erreur de manipulation des fichiers Oracle.

Note : les programmes et processus, qui constituent le coeur d’Oracle, s’executent en tant qu’oracle, et ont conséquemment les droits nécessaires pour écrire dans les fichiers de données, journaux, archives, etc.

Le DBA et le super utilisateur ‘root’ :
lors de l’installation, il est nécessaire d’écrire dans certains répertoires protégés du système (/etc par exemple) ou d’exécuter certaines taches privilégiées.
Cependant l’installation se fait bien en tant qu’Oracle, et l’installeur demande simplement le privilège root pendant la période nécessaire ? ces opérations.
Il execute 2 scripts autonomes root.sh et rootpre.sh, en tant que root.
Il retourne ensuite en mode ‘normal’.
En production les no de ports TCP/IP utilisés par Oracle 10g sont tous > 1024, et ne nécessitent donc pas de privilèges particuliers.

Sur Windows :
Le principe est plus simple. L’install se fait en général en tant qu’administrateur système.