Implicitement le créateur d’un objet (TABLE, VUE , INDEX, etc.) est son propriétaire, et possède tous les droits sur le contenu et le contenant : consultation, mises à jour, insertion , suppression des liognes. Mais aussi modification et suppression de la structure.

En supposant qu’un user ait le droit de créer une table, implicitement il peut faire toutes les opérations suivantes :

SQL> CREATE TABLE test (n integer);
– on fait des modifs
SQL> INSERT INTO test VALUES(1);
SQL> UPDATE test SET n=2;
SQL> COMMIT;
SQL> DELETE FROM test; — on vide la table
–  on modifie la structure
SQL> ALTER TABLE test ADD (c char(1));
– et finalement on supprime structure et contenu eventuel
SQL> DROP TABLE test;

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 qui peut donner des droits d’accès à un autrer utilisateur.
Sinon c’est le DBA (qui a tous les drorts)i

exemples:

SQL> GRANT SELECT ON TAB_CLIENTS TO MARTIN
SQL> GRANT UPDATE, INSERT ON TAB_CLIENTS TO DUPONT

Un utilisateur non propriétaire peut donner des droits sur un objet ne lui appartenant pas : le DBA bien sûr, mais aussi un utilisateur qui a recu des droits et le droit de transferer ce droit (GRANT OPTION)

exemple :

SQL> connect DBA1/DBA1
SQL> GRANT SELECT ON scott.emp TO martin;
SQL> GRANT SELECT, UPDATE, INSERT ON scott.emp TO dupont WITH GRANT OPTION;
SQL> CONNECT dupont/dupont
SQL> GRANT UPDATE ON scott.emp TO martin;

note : ‘GRANT OPTION’ est à utiliser avec parcimonie…

Le type de privilège dépend évidemment de l’objet sur lequel il s’applique. Ceci est résumé dans le tableau suivant :

TABLE	VUE	VUE MAT.	SEQUENCE	PROCEDURE
ALTER 			X				X
DELETE 			X	X	X
EXECUTE 								X
INDEX 			X
INSERT 			X	X	X
REFERENCES (1) 		X	X
SELECT 			X	X	X		X
UPDATE			X	X	X
ON COMMIT REFRESH	X
QUERY REWRITE		X

(1) possibilité de créer une clé étrangère sur la table

Une erreur très répandue consiste à référencer un objet (dont on n’est pas proprétaire), sur lequel on a des droits et qu’on oublie de préfixer…

SQL> SELECT COUNT(*)  from EMP
‘ Table or view doesn’t exists ‘ !!!
– alors que
SQL> SELECT * FROM SCOTT.EMP
–  donne un résultat !!!!

Le cas particulier des droits sur les programmes stockés (packages procédures et fonctions )

Pour exécuter une procédure il faut le droit …EXECUTE PROCEDURE.
Jusque la ca va.
Mais pour les objets sous-jacents à la procédure, Il y a 2 types de droits :
- en tant que créateur de la procédure ( DEFINER’s RIGHT)
- en tant qu’exécuteur de la procédure ( INVOKER’S RIGHT)

Dans les cas simples un utilisateur est propriétaire des tables et des procédures dans le même schéma et par défaut il execute la procédure en tant que créateur et a donc forcément les droits sur les objets du même schéma.

Pour les packages du dictionnaire par contre qui appartiennent à SYS il serait délicat de les exécuter en tant que …SYS, ils sont donc créés avec ‘INVOKER’s RIGHT’

exemple de procédure

SQL> -- c'est lemot réservé AUTHID qui définit les droits 'executeur'
SQL>create or replace procedure TEST
authid current_user is
begin
...