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
• Si l’utilisateur n’a aucun privilège sur l’objet, Oracle retourne l’erreur ORA-00942: Table ou vue inexistante.
• Si l’utilisateur a au moins un privilège sur l’objet, Oracle retourne l’erreur ORA-01031: privilèges insuffisants.
Dans le premier cas, Oracle considère que l’utilisateur n’a normalement aucun moyen de savoir que l’objet accédé
existe : il indique donc que l’objet n’existe pas. Dans le deuxième cas, Oracle considère que l’utilisateur peut savoir que
l’objet existe : il indique donc que le privilège est insuffisant.
b. Attribution d’un privilège objet à un utilisateur : L’ordre SQL GRANT permet d’attribuer un privilège objet.
GRANT { nom_privilège[(liste_colonnes)] [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
TO { nom_utilisateur | PUBLIC } [,...]
[ WITH GRANT OPTION ] ;
Exemple : GRANT SELECT, INSERT, UPDATE(nom,prenom) ON adherent TO user1;
Pour les privilèges INSERT et UPDATE, une liste de colonnes peut être spécifiée afin de limiter le privilège aux colonnes
indiquées.
La clause WITH GRANT OPTION donne au bénéficiaire le droit de transmettre le privilège objet.
Le mot clé ALL permet d’attribuer tous les privilèges. Dans le cas où l’utilisateur qui attribue tous les droits n’est pas le
propriétaire de l’objet, mais un utilisateur qui a reçu certains privilèges sur l’objet avec le droit de les transmettre
(clause WITH GRANT OPTION), le mot clé ALL désigne uniquement tous les privilèges que l’utilisateur a reçus.
Le privilège peut être attribué à un utilisateur ou à tous les utilisateurs (PUBLIC).
Plusieurs privilèges peuvent être attribués à plusieurs utilisateurs en un seul ordre ; par contre, l’attribution des
privilèges objet s’effectue objet par objet.
Le privilège attribué est immédiatement actif.
Pour attribuer un privilège objet, il faut :
• être propriétaire de l’objet ;
• avoir reçu le privilège en question avec la clause WITH GRANT OPTION ;
• ou avoir reçu le privilège système ANY OBJECT PRIVILEGE.
Un utilisateur qui retransmet un privilège qu’il a reçu avec l’option WITH GRANT OPTION doit qualifier le nom de l’objet
avec le nom du propriétaire (car l’objet ne lui appartient pas), sauf s’il existe un synonyme sur l’objet.
Certains privilèges système donnent implicitement des privilèges objet sur tous les objets. Exemple : SELECT ANY
TABLE.
Le DBA a les privilèges système ANY indiqués précédemment ; c’est la raison pour laquelle il peut accéder à n’importe
quel objet sans privilège objet. Depuis la version 9, il a aussi le privilège système ANY OBJECT PRIVILEGE qui lui permet
d’attribuer un privilège objet sur n’importe quel objet, sans avoir reçu le privilège en question WITH GRANT OPTION.
Avant la version 9, ce n’était pas possible.
c. Révocation d’un privilège objet à un utilisateur
L’ordre SQL REVOKE permet de révoquer un privilège objet.
REVOKE { nom_privilège [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
FROM { nom_utilisateur | PUBLIC } [,...] ;
Exemple : REVOKE INSERT, UPDATE ON client FROM user1;
L’ordre REVOKE permet de révoquer à un utilisateur uniquement ce qu’il a reçu en direct (pas 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, le révoquer à l’utilisateur est sans effet ; l’utilisateur continue
d’exercer le privilège : il l’a toujours via PUBLIC.Tous les privilèges objet peuvent être révoqués d’un seul coup avec le
mot clé ALL (REVOKE ALL ON ... FROM ...). Si vous avez attribué un privilège avec l’option WITH GRANT 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. Le privilège est immédiatement enlevé et ne peut plus être exercé.
Pour enlever un privilège objet, il faut :
• être propriétaire de l’objet ;
• avoir reçu le privilège en question avec la clause WITH GRANT OPTION ;
• ou avoir reçu le privilège système ANY OBJECT PRIVILEGE.
Il y a cascade dans la révocation d’un privilège objet qui a été transmis grâce à la clause WITH GRANT OPTION. Si un
privilège a été attribué à Pierre avec l’option WITH GRANT OPTION et que Pierre l’ait transmis à Paul, révoquer le
privilège de Pierre révoque également celui de Paul. Le fonctionnement n’est pas le même que pour les privilèges
système.
3. Rôle
a. Définition: Un rôle est un regroupement nommé de privilèges (système et objet) qui peut être attribué à un
utilisateur. Tous les privilèges regroupés dans le rôle sont alors simultanément attribués à l’utilisateur. Les rôles
permettent de simplifier la gestion des droits. Les principales caractéristiques des rôles sont les suivantes :
• Un rôle peut être attribué à un autre rôle.
• Un utilisateur peut avoir plusieurs rôles.
• Un rôle n’appartient à personne.
La mise en œuvre s’effectue en trois étapes :
• création du rôle ;
• attribution des privilèges (système et objet) au rôle ;
• attribution du rôle aux utilisateurs.
b. Création d’un rôle : L’ordre SQL CREATE ROLE permet de créer un rôle.
CREATE ROLE nom
[ IDENTIFIED { BY mot_de_passe | EXTERNALLY | USING nom_package}
6
| NOT IDENTIFIED ];
Exemple : CREATE ROLE mailing;
Les options sont :
IDENTIFIED BY mot_de_passe : Indique qu’un mot de passe est nécessaire pour activer le rôle.
IDENTIFIED EXTERNALLY : Indique qu’une identification externe est nécessaire pour activer le rôle.
IDENTIFIED USING nom_package : Indique que seul le package peut activer le rôle.
NOT IDENTIFIED : Indique qu’aucune identification n’est nécessaire pour activer le rôle. C’est la valeur par défaut.
Pour créer un rôle, il faut avoir le privilège système CREATE ROLE.
Lors de la création d’un rôle, il est possible de préciser par quel mécanisme le rôle pourra être activé : un mot de passe,
une identification externe (système d’exploitation) ou un package.
L’ordre SQL ALTER rôle permet de modifier un rôle, en l’occurrence le mode d’identification pour pouvoir l’activer.
ALTER ROLE nom
[ IDENTIFIED { BY mot_de_passe | EXTERNALLY | USING nom_package} | NOT IDENTIFIED ];
c. Attribution d’un privilège à un rôle : L’ordre SQL GRANTpermet d’attribuer des privilèges système ou des privilèges
objet à un rôle.
Syntaxe pour les privilèges système
GRANT nom_privilège [,...]
TO nom_rôle [,...]
[ WITH ADMIN OPTION ] ;
Syntaxe pour les privilèges objet
GRANT { nom_privilège[(liste_colonnes)] [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
TO nom_rôle [,...] ;
Exemple :
GRANT CREATE SESSION, CREATE TABLE TO mailing;
GRANT SELECT, INSERT ON adherent TO mailing;
Les syntaxes sont les mêmes que pour l’attribution directe à un utilisateur, à l’exception de la clause WITH GRANT
OPTION qui n’est pas permise pour l’attribution d’un privilège objet à un rôle. Les privilèges attribués sont
immédiatement actifs pour les utilisateurs connectés qui ont le rôle actif. La notion de rôle actif sera présentée un peu
plus loin dans ce chapitre Gérer les droits, section Rôle - Activation ou désactivation d’un rôle. Tout utilisateur a le droit
d’attribuer un privilège à un rôle, du moment qu’il a le droit d’attribuer le privilège ; c’est en cela que le rôle n’appartient
à personne. En l’occurrence, pour attribuer un privilège système à un rôle, il faut avoir reçu le privilège en question avec
la clause WITH ADMIN OPTION ou avoir le privilège système GRANT ANY PRIVILEGE. Pour attribuer un privilège objet à un
rôle, il faut être propriétaire de l’objet, avoir reçu le privilège en question avec la clause WITH GRANT OPTION, ou avoir le
privilège système ANY OBJECT PRIVILEGE.
d. Révocation d’un privilège à un rôle : L’ordre SQL REVOKE permet de révoquer des privilèges système ou des privilèges
objet à un rôle.
Syntaxe pour les privilèges système
REVOKE nom_privilège [ ,...]
FROM nom_rôle [,...] ;
Syntaxe pour les privilèges objet
REVOKE { nom_privilège [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
FROM nom_rôle [,...] ;
Exemple :
REVOKE CREATE TABLE FROM mailing;
REVOKE UPDATE ON adherent FROM mailing;
Les syntaxes sont les mêmes que pour la révocation directe à un utilisateur. D’une manière générale, l’ordre SQL
REVOKE ne permet d’enlever à une "cible" (utilisateur, rôle ou PUBLIC) que ce qui a été attribué explicitement à cette
"cible". Par exemple, si un privilège a été attribué à un rôle, il n’est pas possible de l’enlever directement à un utilisateur
qui a reçu le rôle.
Attention au mélange attribution directe et attribution à un rôle : si un privilège est attribué à un rôle et le rôle à
l’utilisateur et qu’en parallèle le privilège est attribué en direct à l’utilisateur, révoquer le privilège de l’utilisateur ne
l’empêchera pas de pouvoir continuer à l’exercer (via le rôle).
Les privilèges sont immédiatement révoqués et ne peuvent plus être exercés par les utilisateurs connectés qui ont le
rôle actif. La notion de rôle actif sera présentée un peu plus loin dans ce chapitre, section Rôle - Activation ou
désactivation d’un rôle.
Tout utilisateur a le droit de révoquer un privilège d’un rôle, du moment qu’il a le droit de révoquer le privilège (le rôle
n’appartient à personne). En l’occurrence, pour révoquer un privilège système d’un rôle, il faut avoir reçu le privilège en
question avec la clause WITH ADMIN OPTION ou avoir le privilège système GRANT ANY PRIVILEGE. Pour révoquer un
privilège objet d’un rôle, il faut être propriétaire de l’objet, avoir reçu le privilège en question avec la clause WITH GRANT
OPTION, ou avoir le privilège système ANY OBJECT PRIVILEGE.
e. Attribution d’un rôle à un utilisateur ou à un rôle
L’ordre SQL GRANT permet d’attribuer un rôle à un utilisateur ou à un rôle.
Syntaxe
GRANT nom_rôle [,...]
TO { nom_utilisateur | PUBLIC | nom_rôle } [,...]
[ WITH ADMIN OPTION ] ;
Exemple :
GRANT mailing TO user1;
La syntaxe est la même que pour l’attribution d’un privilège système.
Pour attribuer un rôle, il faut avoir reçu le rôle en question avec la clause WITH ADMIN OPTION ou avoir le privilège
système GRANT ANY ROLE. Le créateur d’un rôle n’est pas propriétaire du rôle mais le rôle lui est attribué avec l’option
WITH ADMIN OPTION ; il peut donc attribuer le rôle qu’il a créé.
7
Le rôle attribué n’est pas immédiatement actif si l’utilisateur est déjà connecté.
La clause WITH ADMIN OPTION donne aussi le droit de modifier (ordre SQL ALTER ROLE) et de supprimer le rôle (ordre
SQL DROP ROLE).
Un utilisateur peut avoir plusieurs rôles ; dans ce cas, les privilèges se cumulent (il n’y a pas de privilège "négatif").
f. Révocation d’un rôle à un utilisateur ou à un rôle
L’ordre SQL REVOKE permet de révoquer un rôle.
Syntaxe
REVOKE nom_rôle [,...]
FROM { nom_utilisateur | PUBLIC | nom_rôle } [,...] ;
Exemple :
REVOKE mailing FROM user1;
La syntaxe est la même que pour la révocation d’un privilège système. Pour enlever un rôle, il faut avoir reçu le rôle en
question avec la clause WITH ADMIN OPTION ou avoir le privilège système GRANT ANY ROLE. Le créateur du rôle ayant
reçu ce dernier avec la clause WITH ADMIN OPTION, il peut donc enlever le rôle.
Lorsqu’un rôle est révoqué, les utilisateurs connectés avec le rôle actif peuvent continuer à exercer les privilèges
associés, jusqu’à la fin de la session ou jusqu’à la désactivation du rôle.
g. Suppression d’un rôle : L’ordre SQL DROP ROLE permet de supprimer un rôle.
DROP ROLE nom_rôle ;
Exemple :
DROP ROLE mailing;
Pour supprimer un rôle, il faut avoir reçu le rôle en question avec la clause WITH ADMIN OPTION ou avoir le privilège
système DROP ANY ROLE.
Le rôle est immédiatement enlevé aux utilisateurs ; les privilèges associés ne peuvent plus être exercés.
h. Activation ou désactivation d’un rôle : Un rôle attribué à un utilisateur (directement ou via un autre rôle) est
par défaut automatiquement activé lors de la connexion de l’utilisateur.
Si l’utilisateur est connecté au moment de l’attribution, l’activation immédiate n’est pas automatique. L’utilisateur peut
activer le rôle grâce à l’ordre SQL SET ROLE.
De plus, parmi les rôles attribués à l’utilisateur, il est possible de définir ceux qui sont effectivement automatiquement
activés lors de la connexion de l’utilisateur. Ce sont les rôles par défaut définis par un ordre SQL ALTER USER.
L’utilisateur peut ensuite activer les autres grâce à l’ordre SQL SET ROLE.
Utiliser plusieurs rôles sans qu’ils soient tous actifs simultanément présente deux intérêts :
• Il existe un paramètre, MAX_ENABLED_ROLES (30 par défaut), qui limite le nombre de rôles actifs simultanément pour
un utilisateur. Si un utilisateur est susceptible d’employer un nombre de rôles supérieur à cette limite, il est possible
d’en désactiver certains pour en activer d’autres.
• Des rôles, protégés par des mots de passe, peuvent être attribués à des utilisateurs, mais inactifs par défaut, et sans
donner le mot de passe à l’utilisateur ; ce sont alors les applications qui activent les rôles dont elles ont besoin, en
fournissant le mot de passe. De cette manière, en dehors de l’application en question, l’utilisateur n’a aucun moyen
d’activer et d’utiliser le rôle (et éventuellement de faire des erreurs).
L’ordre SQL ALTER USER permet de définir les rôles par défaut d’un utilisateur.
Syntaxe
ALTER USER nom_utilisateur DEFAULT ROLE
{ nom_rôle [,...] | ALL [ EXCEPT nom_rôle [,...] ] | NONE } ;
Exemple :
ALTER USER user1 DEFAULT ROLE mailing;
ALTER USER vdep DEFAULT ROLE ALL EXCEPT mailing;
Les options sont :
ALL
Tous les rôles attribués à l’utilisateur sont activés par défaut. La clause EXCEPT permet d’en enlever certains.
NONE
Aucun des rôles attribués à l’utilisateur n’est activé par défaut.
Cet ordre SQL annule et remplace la situation actuelle des rôles par défaut ; elle n’ajoute pas ou n’enlève pas les rôles à
la liste actuelle. Les rôles attribués à un utilisateur qui a déjà des rôles par défaut, ne sont pas définis par défaut.
L’ordre SQL SET ROLE permet d’activer ou de désactiver un rôle.
Syntaxe
SET ROLE
{ nom_rôle [ IDENTIFIED BY mot_de_passe ] [,...]
| ALL [ EXCEPT nom_rôle [,...] ] | NONE } ;
Exemple :
-- L’utilisateur VDEP active le rôle MAILING
SET ROLE mailing;
Les options sont :
IDENTIFIED BY
Donne le mot de passe qui permet d’activer le rôle.
ALL
Tous les rôles attribués à l’utilisateur sont activés. La clause EXCEPT permet d’en enlever certains.
NONE
Aucun des rôles attribués à l’utilisateur n’est activé (désactive donc tous les rôles).
Les rôles doivent avoir préalablement été attribués à un utilisateur ; il n’est donc pas possible de s’autoattribuer un rôle
en l’activant (heureusement).
Cet ordre SQL annule et remplace les rôles actuellement actifs (pas d’ajout).
L’option ALL ne peut pas être utilisée sur des rôles protégés par un mot de passe.
Les rôles définis avec l’option IDENTIFIED USING nom_package ne peuvent être activés de la sorte qu’à partir du
package spécifié.
8
La procédure SET_ROLE du package DBMS_SESSION permet de faire la même chose (voir la documentation "PL/SQL
Packages and Types Reference").
i. Limitation des rôles : Pour développer un objet (une vue ou un programme stocké) qui utilise des objets d’un autre
schéma, il faut avoir reçu des droits en direct sur les objets, pas à travers un rôle.
Par ailleurs, lors de l’exécution d’un programme stocké, les rôles activés de l’utilisateur appelant ne sont pris en compte
que si le programme stocké est conçus pour s’exécuter avec les droits de l’appelant (clause AUTHID CURRENT_USER).
j. Rôles prédéfinis : Oracle propose en standard un grand nombre de rôle prédéfinis, parmi lesquels :
CONNECT : Autorise la connexion (contient uniquement le privilège système CREATE SESSION).
Ressource : Permet la création des principaux objets d’un schéma (table, vue...).
DBA : Donne tous les privilèges système avec l’option WITH ADMIN OPTION.
Les vues DBA_SYS_PRIVS et DBA_TAB_PRIVS permettent de connaître les privilèges regroupés dans ces rôles prédéfinis.
Oracle préconise de ne pas utiliser les rôles prédéfinis CONNECT, RESOURCE et DBA mais de créer ses propres rôles.
Depuis la version 10.2 (10 g Release 2), le rôle CONNECT ne contient plus que le privilège système CREATE SESSION.
Avant cette version, ce rôle contenait d’autres privilèges qui permettaient de créer les principaux objets d’un schéma
(table, vue, etc.) ou de modifier la session (privilège système ALTER SESSION). Depuis la version 10.2, si vous avez
besoin d’attribuer de tels droits à un utilisateur, le rôle CONNECT ne suffit pas ; par contre, vous pouvez attribuer ces
droits directement à l’utilisateur ou via un rôle spécifique que vous créez.
4. Trouver des informations sur les droits : Plusieurs vues du dictionnaire de données permettent d’obtenir des
informations sur les privilèges système :
• DBA_SYS_PRIVS : privilèges système attribués aux utilisateurs (ou aux rôles) ;
• SESSION_PRIVS : privilèges système actuellement actifs dans la session (obtenus directement ou via un rôle) ;
• SYSTEM_PRIVILEGE_MAP : liste de tous les privilèges système.
Synthèse : Une base Oracle contient en général quatre types de comptes.
Administration : Un tel compte a tous les privilèges système nécessaires, notamment pour la gestion des structures de
stockage et la gestion des utilisateurs. Les comptes d’administration ont, de plus, un accès complet au dictionnaire de
données. Ces privilèges peuvent être obtenus par l’intermédiaire du rôle DBA ou d’un rôle équivalent.
Développement / Hébergement du schéma applicatif : Un tel compte a les privilèges système nécessaires pour la
création des différents types d’objets (tables, vues, procédures...) et il possède un quota sur au moins un tablespace.Les
privilèges système requis peuvent être obtenus par l’intermédiaire des rôles CONNECT et RESOURCE, ou d’un rôle
équivalent que vous avez créé (conseillé). Pour les comptes de développement, il peut être judicieux de prévoir un
tablespace dédié et de définir un quota uniquement sur ce tablespace. Dans l’idéal, il est préférable d’utiliser une base
de données à part pour le développement. Le compte "propriétaire" d’une application a généralement des quotas
illimités sur les tablespaces (de tables et d’index) dédiés à l’application.
Utilisateur final : Un tel compte a besoin de très peu de privilèges système : CREATE SESSION (obligatoire), ALTER
SESSION (parfois nécessaire), et c’est généralement tout. Par contre, il possède des privilèges objet sur les objets du
schéma applicatif, généralement par l’intermédiaire d’un rôle. Les comptes des utilisateurs finaux n’ont besoin d’aucun
quota dans les tablespaces. Ils accèdent aux objets du schéma applicatif grâce aux privilèges objet et l’écriture des
requêtes est simplifiée par l’utilisation de synonymes publics ou par l’exécution de l’ordre SQL ALTER SESSION SET
CURRENT_SCHEMA. Les profils peuvent être utilisés en plus, pour contrôler l’utilisation de certaines ressources ou mettre
en œuvre une politique de gestion des mots de passe.
9