Chapitre 1 : Rôle profile privilèges

Principes: Pour la gestion de la sécurité, Oracle permet :
•de définir les utilisateurs qui peuvent se connecter à la base de données (avec une identification par le système
d’exploitation ou par la base de données) ;
•de définir dans quel(s) tablespace(s) un utilisateur peut créer des objets (éventuellement aucun) ;
•de limiter l’utilisation des ressources système ;
•d’imposer une politique de gestion de mots de passe (expiration périodique, non- réutilisation avant un certain temps)
•de définir les droits de chaque utilisateur à l’intérieur de la base de données.
Dans une base de données Oracle, les droits des utilisateurs sont gérés avec la notion de privilège. Un privilège est le
droit :
•d’exécuter un ordre SQL en général (ex : créer une table) : c’est la notion de privilège système ;
•d’accéder à un objet d’un autre utilisateur (ex : MAJ les données d'une table) : c’est la notion de privilège objet.
Les privilèges peuvent être attribués directement aux utilisateurs ou par l’intermédiaire de rôles. Un rôle est un
regroupement nommé de privilèges (systèmes et objets) qui peut être attribué en tant que tel à un utilisateur ; cet
utilisateur reçoit alors automatiquement les privilèges contenus dans le rôle. Les rôles facilitent la gestion des droits.
Créer et modifier les utilisateurs :
1. Mode d’identification de l’utilisateur : Un utilisateur peut être identifié par Oracle ou par le système
d’exploitation. Les deux modes d’identification sont utilisables simultanément dans la même base de données.
a. Identification par Oracle : L’utilisateur se connecte à la base en saisissant un nom et un mot de passe. Oracle
vérifie le nom et le mot de passe de l’utilisateur : SQL> CONNECT nomuser/motdepasse
b. Identification par le système d’exploitation : L’utilisateur se connecte à la base sans saisir de nom ni de mot de
passe : SQL> CONNECT /
Oracle ne vérifie pas le mot de passe mais contrôle simplement que le nom de l’utilisateur, au niveau du système
d’exploitation, correspond à un nom d’utilisateur dans la base de données. L’identification initiale a été réalisée par le
système d’exploitation. Les fonctionnalités de gestion des mots de passe proposées par Oracle ne sont pas utilisables
(ce n’est pas Oracle qui gère le mot de passe).
2. Création d’un utilisateur : L’ordre SQL CREATE USER permet de créer un nouvel utilisateur.
CREATE USER nom IDENTIFIED { BY mot_de_passe | EXTERNALLY | }
[ DEFAULT TABLESPACE nom_tablespace ]
[ TEMPORARY TABLESPACE nom_tablespace ]
[ QUOTA { valeur [K|M] | UNLIMITED } ON nom_tablespace [,...] ]
[ PROFILE nom_profil ]
[ PASSWORD EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK } ] ;
Exemple : Utilisateur identifié par Oracle avec des clauses supplémentaires
CREATE USER user1 IDENTIFIED BY tempo
DEFAULT TABLESPACE data
QUOTA UNLIMITED ON data
PASSWORD EXPIRE;
Pour qu’un nouvel utilisateur puisse effectivement se connecter, il faut en plus lui donner le droit de le faire, en lui
attribuant le privilège système CREATE SESSION. Il est donc possible d’avoir des comptes pour les utilisateurs sans que
ces derniers aient le droit de se connecter. Cette fonctionnalité peut toujours être utilisée mais il est plus simple de
verrouiller/déverrouiller explicitement le compte (ACCOUNT LOCK | UNLOCK).
Les options de l’ordre SQL CREATE USER sont :
nom : Le nom de l’utilisateur doit respecter les règles de nommage d’Oracle. Si ce n’est pas le cas, il faut placer le nom
entre guillemets.
IDENTIFIED : Cette clause indique si l’utilisateur est identifié par le système d’exploitation (EXTERNALLY) ou par Oracle
(BY mot_de_passe). Dans le cas d’une identification par Oracle, le mot de passe initial de l’utilisateur est spécifié. Depuis
la version 11, les mots de passe sont par défaut, sensibles à la casse (paramètre SEC_CASE_SENSITIVE_LOGON égal à
TRUE par défaut). Si vous souhaitez avoir des mots de passe non sensibles à la casse, il suffit d’affecter la valeur FALSE
au paramètre SEC_CASE_SENSITIVE_LOGON (mais ce n’est pas conseillé pour la sécurité).
DEFAULT TABLESPACE : Cette clause indique dans quel tablespace les segments de l’utilisateur sont créés par défaut
(c’est-à-dire si aucune clause TABLESPACE n’est présente lors de la création du segment). Si la clause est omise, le
tablespace permanent par défaut de la base de données est affecté à l’utilisateur. La notion de tablespace par défaut
n’empêche pas l’utilisateur de créer des objets dans un autre tablespace (s’il a un quota sur le tablespace en
question) ; elle permet simplement de spécifier un tablespace par défaut si l’utilisateur omet la clause TABLESPACE lors
de la création d’un segment. Cette clause présente surtout un intérêt pour les utilisateurs qui peuvent créer des
segments : les développeurs, les testeurs, plus rarement les utilisateurs finaux.
TEMPORARY TABLESPACE : Cette clause indique dans quel tablespace les segments temporaires de l’utilisateur sont
créés (lors d’un tri, par exemple). Vous pouvez indiquer le nom d’un tablespace temporaire, ou le nom d’un groupe de
tablespaces temporaires. Si la clause est omise, le tablespace temporaire par défaut de la base de données est affecté à
l’utilisateur.
QUOTA : Cette clause indique dans quel(s) tablespace(s) l’utilisateur peut créer des objets, et jusqu’à quelle limite. La
notion de QUOTA permet de limiter l’espace qu’un utilisateur peut employer dans un tablespace avec les segments qu’il
crée. Cette fonctionnalité ne concerne que les utilisateurs qui peuvent créer des segments, et non les utilisateurs finaux
d’un applicatif qui se contentent d’employer des objets déjà existants et qui appartiennent généralement à un compte
distinct (en quelque sorte le "propriétaire" de l’application). Par défaut, les utilisateurs n’ont aucun quota sur aucun
tablespace, sauf les DBA qui ont un quota illimité sur tous les tablespaces. Si un utilisateur a le droit de créer des
segments, il faut lui donner explicitement un quota sur au moins un tablespace. Le fait qu’une clause DEFAULT
TABLESPACE ait été utilisée ne donne aucun quota sur le tablespace en question ; ce sont deux mécanismes différents.
Dans la pratique, il ne faut donner des quotas qu’aux utilisateurs qui en ont besoin (les développeurs, le compte
1

"propriétaire" de l’application) et uniquement sur les tablespaces strictement nécessaires et suffisants. En l’occurrence,
il vaut mieux éviter de donner des quotas à ces utilisateurs sur le tablespace SYSTEM ou le tablespace SYSAUX.
Si un utilisateur cherche à créer un segment dans un tablespace sur lequel il n’a pas de quota ou qui aurait pour effet de
dépasser le quota alloué à cet utilisateur, une erreur est retournée :
PROFILE :Cette clause indique le profil attribué à l’utilisateur.
PASSWORD EXPIRE : Cette clause permet de forcer une modification du mot de passe lors de la première connexion (le
mot de passe de l’utilisateur est expiré). Cette clause est sans objet si l’utilisateur est identifié par le système
d’exploitation. Si le compte est créé avec l’option PASSWORD EXPIRE, l’utilisateur, lors de sa première connexion, sera
invité à changer le mot de passe qui lui a été attribué initialement.
ACCOUNT : LOCK : le compte est verrouillé et la connexion interdite. UNLOCK : le compte n’est pas verrouillé et la
connexion autorisée (valeur par défaut). Si le compte est créé avec l’option LOCK, le compte existe mais l’utilisateur ne
peut pas se connecter. L’ordre SQL ALTER USER pourra être utilisé plus tard pour déverrouiller le compte de l’utilisateur.
3. Modification d’un utilisateur : L’ordre SQL ALTER USER permet de modifier un utilisateur.
ALTER USER nom
[ IDENTIFIED { BY mot_de_passe | EXTERNALLY | } ]
[ DEFAULT TABLESPACE nom_tablespace ]
[ TEMPORARY TABLESPACE nom_tablespace ]
[ QUOTA { valeur [K|M] | UNLIMITED } ON nom_tablespace [,...] ]
[ PROFILE nom_profil ]
[ PASSWORD EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK } ] ;
Les clauses sont les mêmes que pour la création.
Exemples :
•Modification du mot de passe d’un utilisateur : ALTER USER user1 IDENTIFIED BY tempo PASSWORD EXPIRE;
•Modification du tablespace par défaut et attribution de quotas
ALTER USER user1 DEFAULT TABLESPACE test QUOTA UNLIMITED ON test QUOTA 10M ON data;
•Verrouillage d’un compte : ALTER USER user1 ACCOUNT LOCK;
•Déverrouillage d’un compte : ALTER USER user1 ACCOUNT UNLOCK;
Le premier exemple permet de modifier le mot de passe d’un utilisateur en le forçant à en changer lors de sa première
connexion ; cette technique peut être employée si l’utilisateur a perdu son mot de passe (le DBA n’a aucun moyen de
connaître le mot de passe des utilisateurs). Le deuxième exemple permet de modifier le tablespace par défaut de
l’utilisateur et de lui attribuer des quotas sur deux tablespaces. Le troisième exemple peut être utilisé pour interdire
temporairement à un utilisateur de se connecter. S’il est actuellement connecté, il n’est pas déconnecté. Le quatrième
exemple peut être utilisé pour autoriser de nouveau un utilisateur à se connecter. Diminuer un quota, ou le mettre à 0,
ne supprime pas les objets déjà créés par l’utilisateur.
4. Suppression d’un utilisateur : L’ordre SQL DROP USER permet de supprimer un utilisateur.
DROP USER nom [ CASCADE ] ;
Exemple : DROP USER user1 CASCADE;
Si l’utilisateur possède des objets, l’option CASCADE doit être présente pour forcer la suppression préalable des objets.
Un utilisateur actuellement connecté ne peut pas être supprimé.
5. Trouver des informations sur les utilisateurs : Plusieurs vues du dictionnaire de données permettent
d’obtenir des informations sur les utilisateurs :
•DBA_USERS : informations sur les utilisateurs ;
•DBA_TS_QUOTAS : informations sur les quotas des utilisateurs.
Utiliser les profils
•1. Présentation : Un profil est un ensemble nommé de limitations de ressources qui peut être attribué à un
utilisateur. Les ressources suivantes peuvent être limitées :
•temps CPU par appel et/ou par session ;
•nombre de lectures logiques par appel et/ou par session ;
•nombre de sessions ouvertes simultanément par un utilisateur ;
•temps d’inactivité par session ;
•durée totale de la session ;
•quantité de mémoire privée dans la SGA (configuration serveurs partagés uniquement).
Une lecture logique correspond à une lecture de bloc lors d’une requête, que ce bloc soit déjà présent en mémoire ou lu
sur disque (dans ce cas, la lecture logique correspond aussi à une lecture physique). Les profils peuvent aussi être
utilisés pour mettre en œuvre une politique de gestion des mots de passe.
Les fonctionnalités suivantes peuvent être mises en œuvre :
•verrouillage de compte (et durée de verrouillage) au-delà d’un certain nombre d’échecs de tentative de connexion ;
•durée de vie des mots de passe (avec éventuellement une période de grâce) ;
•non-réutilisation d’un mot de passe avant un certain temps ou avant un certain nombre de changements ;
•complexité du mot de passe.
Le profil nommé DEFAULT est automatiquement créé lors de la création de la base de données. Ce profil est attribué par
défaut aux utilisateurs. Par défaut, ce profil DEFAULT n’impose aucune limite pour les ressources. La limitation des
ressources à l’aide des profils n’offre pas de nombreuses possibilités. Si vous souhaitez contrôler plus précisément
l’attribution de ressources (CPU, espace d’annulation, durée d’inactivité) à des utilisateurs ou groupes d’utilisateurs,
vous pouvez utiliser le Database Resource Manager . La mise en œuvre de cette fonctionnalité s’effectue grâce au
package DBMS_RESOURCE_MANAGER.
2. Création d’un profil : L’ordre SQL CREATE PROFILE permet de créer un nouveau profil.
2

CREATE PROFILE nom LIMIT
[ SESSIONS_PER_USER { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
[ CONNECT_TIME { valeur | UNLIMITED | DEFAULT } ]
[ IDLE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ LOGICAL_READS_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
[ LOGICAL_READS_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
[ COMPOSITE_LIMIT { valeur | UNLIMITED | DEFAULT } ]
[ PRIVATE_SGA { valeur [K|M] | UNLIMITED | DEFAULT } ]
[ FAILED_LOGIN_ATTEMPTS { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_LIFE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_REUSE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_REUSE_MAX { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_LOCK_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_GRACE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_VERIFY_FUNCTION { nom_fonction | NULL | DEFAULT } ] ;
Exemple :
CREATE PROFILE exploitation LIMIT
SESSIONS_PER_USER 3
IDLE_TIME 30
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LIFE_TIME 30
PASSWORD_REUSE_TIME 180
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_GRACE_TIME 3
PASSWORD_VERIFY_FUNCTION verif_mdp_exploitation ;
Les limitations de ressources sont les suivantes :
SESSIONS_PER_USER : Nombre de sessions simultanées.
CPU_PER_SESSION : CPU totale par session (1/100 s).
CPU_PER_CALL : CPU totale par appel (1/100 s).
CONNECT_TIME : Durée totale de connexion (minutes).
IDLE_TIME : Durée d’inactivité (minutes).
LOGICAL_READS_PER_SESSION: Nombre de lectures logiques par session.
LOGICAL_READS_PER_CALL: Nombre de lectures logiques par appel.
PRIVATE_SGA: Quantité de mémoire privée dans la SGA.
COMPOSITE_LIMIT: Somme pondérée de 2, 4, 6 et 8
Les limitations relatives aux mots de passe sont les suivantes :
FAILED_LOGIN_ATTEMPTS : Nombre d’échecs de tentative de connexion autorisés avant verrouillage du compte.
PASSWORD_LOCK_TIME : Durée du verrouillage (jours), 1 dans le profil DEFAULT.
PASSWORD_LIFE_TIME : Durée de vie du mot de passe (jours), 180 dans le profil DEFAULT.
PASSWORD_GRACE_TIME : Période de grâce après expiration du mot de passe (jours), 7 dans le profil DEFAULT.
PASSWORD_REUSE_TIME:Nombre de jours pendant lequel un mot de passe ne peut pas être réutilisé.
PASSWORD_REUSE_MAX: Nombre de changements de mot de passe avant qu’un mot de passe puisse être réutilisé.
PASSWORD_VERIFY_FUNCTION: Fonction de vérification de la complexité du mot de passe.
La limite PASSWORD_VERIFY_FUNCTION permet de spécifier une fonction PL/SQL qui sera utilisée pour vérifier, si le mot
de passe saisi par l’utilisateur respecte bien certaines règles. Une valeur NULL permet de ne pas utiliser de fonction de
vérification. Cette fonction doit accepter trois paramètres en entrée (le nom de l’utilisateur, son nouveau mot de passe
et son ancien mot de passe) et retourner un booléen.
Une limite non spécifiée dans un profil prend la valeur DEFAULT.
3. Modification d’un profil : L’ordre SQL ALTER PROFILE permet de modifier un profil.
ALTER PROFILE nom LIMIT
[ SESSIONS_PER_USER { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
[ CONNECT_TIME { valeur | UNLIMITED | DEFAULT } ]
[ IDLE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ LOGICAL_READS_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
[ LOGICAL_READS_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
[ COMPOSITE_LIMIT { valeur | UNLIMITED | DEFAULT } ]
[ PRIVATE_SGA { valeur [K|M] | UNLIMITED | DEFAULT } ]
[ FAILED_LOGIN_ATTEMPTS { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_LIFE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_REUSE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_REUSE_MAX { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_LOCK_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_GRACE_TIME { valeur | UNLIMITED | DEFAULT } ]
[ PASSWORD_VERIFY_FUNCTION { nom_fonction | NULL | DEFAULT } ] ;
Exemple :
•Modification du profil DEFAULT
ALTER PROFILE default LIMIT
SESSIONS_PER_USER 3
IDLE_TIME 30
3

FAILED_LOGIN_ATTEMPTS 5;
-- les autres paramètres gardent la valeur par défaut (UNLIMITED)
•Modification d’un autre profil
ALTER PROFILE exploitation LIMIT
SESSIONS_PER_USER 5 -- passe de 3 à 5
IDLE_TIME UNLIMITED -- suppression de la limite
FAILED_LOGIN_ATTEMPTS DEFAULT; -- prend la valeur par défaut (5)
-- le reste est inchangé
Les options sont les mêmes que pour l’ordre SQL CREATE PROFILE. La modification d’un profil n’affecte les utilisateurs
qu’à leur prochaine connexion ; elle n’est pas prise en compte immédiatement pour les utilisateurs déjà connectés.
Modifier le profil DEFAULT affecte aussi les profils qui ont des limites spécifiées à DEFAULT.
4. Affectation d’un profil à un utilisateur : Un profil peut être attribué à un utilisateur :
•lors de la création de l’utilisateur (CREATE USER) ;
•lors d’une modification de l’utilisateur (ALTER USER).
Exemples : Lors de la création de l’utilisateur
CREATE USER user2 IDENTIFIED BY tempo
TEMPORARY TABLESPACE temp
PROFILE exploitation
PASSWORD EXPIRE;
Lors d’une modification de l’utilisateur
•Affectation d’un profil : ALTER USER user1 PROFILE exploitation;
•Réaffectation du profil DEFAULT : ALTER USER user1 PROFILE DEFAULT;
L’affectation d’un nouveau profil à des utilisateurs ne prend effet qu’à leur prochaine connexion.
Par défaut, un utilisateur est créé avec le profil DEFAULT.
5. Activation de la limitation des ressources : Par défaut, le contrôle de la limitation des ressources n’est pas
activé. Créer des profils et les affecter aux utilisateurs n’a aucun effet. Pour activer le contrôle de la limitation des
ressources, il faut passer le paramètre RESOURCE_LIMIT à TRUE (FALSE par défaut) :
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE [ clause_SCOPE ];
N’oubliez pas d’utiliser la clause SCOPE = BOTH pour rendre la modification persistante en cas de redémarrage de la
base de données.
6. Suppression d’un profil : L’ordre SQL DROP PROFILE permet de supprimer un profil.
DROP PROFILE nom [ CASCADE ] ;
Exemple :
DROP PROFILE exploitation CASCADE;
Si le profil est attribué à des utilisateurs, l’option CASCADE doit être présente. Si le profil est attribué à des utilisateurs et
que l’option CASCADE soit absente, une erreur est retournée. Le profil DEFAULT est affecté en remplacement aux
utilisateurs concernés. La suppression d’un profil n’affecte les utilisateurs qu’à leur prochaine connexion. Le profil
DEFAULT ne peut pas être supprimé.
7. Trouver des informations sur les profils : Plusieurs vues du dictionnaire de données permettent d’obtenir
des informations sur les profils :
•DBA_USERS : informations sur les utilisateurs, dont le profil attribué (colonne PROFILE) ;
•DBA_PROFILES : informations sur les profils.
Gérer les droits
1. Privilège système
•a. Définition : Un privilège système est le droit d’exécuter un ordre SQL en général, par exemple créer une table.
Chaque ordre SQL a généralement, au moins, un privilège système associé qui porte le même nom que l’ordre SQL. Par
exemple, l’ordre SQL CREATE TABLE possède un privilège système associé CREATE TABLE (donne le droit de créer une
table dans son propre schéma). Certains privilèges système reprennent le nom de l’ordre SQL avec le mot clé ANY. Dans
ce cas, le privilège système permet d’exécuter l’ordre dans n’importe quel schéma de la base de données. Par exemple,
le privilège système CREATE ANY TABLE donne le droit de créer une table dans n’importe quel schéma de la base de
données. Lorsque l’ordre SQL concerné n’est pas relatif aux objets d’un schéma, il n’y a pas de privilège ANY (ANY veut
dire dans n’importe quel schéma) : par exemple, le privilège pour créer un tablespace est CREATE TABLESPACE ; il n’y a
pas de CREATE ANY TABLESPACE (un tablespace n’appartient pas à un schéma).
Les privilèges système sont source de pouvoir et de danger, surtout ceux qui concernent la gestion des utilisateurs et
des droits (CREATE USER, ALTER USER, DROP USER, GRANT ANY PRIVILEGE, GRANT ANY ROLE) et ceux qui permettent
de supprimer des objets (DROP ANY TABLE, DROP TABLESPACE, etc.) ; les privilèges système doivent donc être attribués
avec parcimonie (notamment les privilèges ANY). Pensez que si vous donnez le privilège ALTER USER à un utilisateur, il
pourra modifier les comptes utilisateur (changer les mots de passe par exemple), dont le vôtre.
Quelques privilèges système particuliers :
CREATE SESSION : Donne le droit à l’utilisateur de se connecter.
SELECT ANY DICTIONARY : Donne le droit à l’utilisateur d’interroger n’importe quel objet du dictionnaire de données
dans le schéma SYS. Ce privilège est nécessaire pour les utilisateurs non DBA qui souhaitent employer le Database
Control. Le privilège SELECT ANY DICTIONARY est intéressant car il permet de donner à un utilisateur le droit de lire les
vues DBA sans pour autant être DBA. Les privilèges système sont principalement utilisés pour contrôler l’emploi des
ordres DDL et donc, plutôt destinés aux administrateurs, aux développeurs, au compte propriétaire d’une application et
très rarement à l’utilisateur final d’une application.
La vue SYSTEM_PRIVILEGE_MAP donne la liste de tous les privilèges système.
b. Attribution d’un privilège système à un utilisateur
L’ordre SQL GRANT permet d’attribuer un privilège système.
4

GRANT nom_privilège [,...]
TO { nom_utilisateur | PUBLIC } [,...]
[ WITH ADMIN OPTION ] ;
Exemple : GRANT CREATE SESSION, CREATE TABLE TO user1;
Le privilège peut être attribué à un utilisateur ou à tous les utilisateurs (PUBLIC).
La clause WITH ADMIN OPTION donne au bénéficiaire le droit de transmettre le privilège système.
Le privilège attribué est immédiatement actif.
Pour attribuer un privilège système, il faut avoir reçu :
•le privilège en question avec la clause WITH ADMIN OPTION ;
•ou le privilège système GRANT ANY PRIVILEGE.
Plusieurs privilèges peuvent être attribués à plusieurs utilisateurs en un seul ordre. Tous les privilèges système peuvent
être attribués d’un seul coup avec le mot clé ALL PRIVILEGES (GRANT ALL PRIVILEGES TO ...). Cette possibilité est à
manipuler avec beaucoup de précautions.
c. Révocation d’un privilège système à un utilisateur
L’ordre SQL REVOKE permet de révoquer un privilège système.
Syntaxe
REVOKE nom_privilège [,...]
FROM { nom_utilisateur | PUBLIC } [,...] ;
Exemple :
REVOKE CREATE TABLE FROM user1;
Le privilège est immédiatement révoqué et ne peut plus être exercé.
Pour révoquer un privilège système, il faut avoir reçu :
•le privilège en question avec la clause WITH ADMIN OPTION ;
•ou le privilège système GRANT ANY PRIVILEGE.
Il n’y a pas de cascade dans la révocation d’un privilège système qui a été transmis grâce à la clause WITH ADMIN
OPTION. Si un privilège a été attribué à Pierre avec l’option WITH ADMIN OPTION et que Pierre l’ait transmis à Paul,
révoquer le privilège de Pierre est sans effet sur le privilège transmis par Pierre à Paul. La clause WITH ADMIN OPTION
est donc doublement dangereuse.
L’ordre REVOKE permet de révoquer uniquement les privilèges qu’un utilisateur a reçu en direct (non les privilèges qu’il
a implicitement via PUBLIC). Il en est de même pour PUBLIC : vous ne pouvez pas révoquer à PUBLIC un privilège non
attribué à PUBLIC en pensant l’enlever ainsi à tout le monde.
Si un privilège a été attribué à un utilisateur et à PUBLIC, la révocation de l’utilisateur est sans effet sur la possibilité
pour l’utilisateur de continuer à exercer le privilège : il le possède toujours via PUBLIC.
Tous les privilèges système peuvent être révoqués d’un seul coup avec le mot clé ALL PRIVILEGES (REVOKE ALL
PRIVILEGES FROM ...).
Si vous avez attribué un privilège avec l’option WITH ADMIN OPTION et que vous souhaitiez enlever cette possibilité de
transmission, il faut révoquer le privilège et l’attribuer de nouveau sans l’option.
d. Les privilèges système SYSDBA et SYSOPER
Nous avons déjà vu que les privilèges SYSDBA et SYSOPER étaient nécessaires pour réaliser certaines opérations
d’administration (démarrage/arrêt/création de base). Ces privilèges peuvent être contrôlés, soit par une appartenance à
un groupe particulier du système d’exploitation, soit par un fichier de mot de passe. Dans le cas de l’utilisation d’un
fichier de mot de passe, par défaut, seul SYS a reçu les privilèges SYSDBA et SYSOPER. Pour attribuer le privilège
SYSDBA, il faut être connecté AS SYSDBA ; pour attribuer le privilège SYSOPER, il faut être connecté AS SYSDBA ou AS
SYSOPER.
La vue V$PWFILE_USERS <permet de lister les utilisateurs qui ont reçu les privilèges SYSDBA ou SYSOPER ; cette vue est
toujours vide si REMOTE_LOGIN_PASSWORDFILE= NONE.
2. Privilège objet
a. Définition : Un privilège objet est le droit d’accéder à un objet d’un autre utilisateur : par exemple, mettre à jour les
données de la table CLIENT. Par défaut, seul le propriétaire d’un objet a le droit d’y accéder. Pour qu’un autre utilisateur
puisse accéder à l’objet, le propriétaire de l’objet doit lui donner un privilège objet.
Les principaux privilèges objet sont les suivants :
Privilège Table Vue Séquence Programme
SELECT x x x
INSERT x x
UPDATE x x
DELETE x x
EXECUTE x
Dans le tableau, la colonne "Programme" désigne les procédures et fonctions stockées et les packages.
Ces privilèges donnent les droits suivants :
SELECT : Droit de lecture des données (exécution de l’ordre SQL SELECT).
INSERT : Droit de création des données (exécution de l’ordre SQL INSERT).
UPDATE: Droit de mise à jour des données (exécution de l’ordre SQL UPDATE).
DELETE: Droit de suppression des données (exécution de l’ordre SQL DELETE).
EXECUTE : Droit d’exécution du programme.
Les privilèges objet sont destinés à contrôler l’accès à des objets bien identifiés. Par exemple : le droit de créer une
commande (i.e. le droit de faire un INSERT dans la table COMMANDE), le droit de supprimer une fiche client (i.e. le droit
de faire un DELETE dans la table CLIENT).
Ils sont principalement employés pour permettre aux utilisateurs finaux d’une application d’accéder, directement ou via
une interface utilisateur, aux objets de l’application créés dans un compte "propriétaire" de l’application (car par défaut,
seul le propriétaire d’un objet a le droit d’y accéder).
Le message d’erreur retourné par Oracle, lorsqu’un utilisateur n’a pas le privilège requis pour réaliser une action sur un
objet, est déterminé différemment si l’utilisateur possède ou non au moins un privilège sur l’objet :
5