Code : Console
ERROR 1142 (42000): SELECT command denied to user 'john'@'localhost' for table 'adoption'
Par contre, john a le droit d'exécuter les procédures de la base de données elevage. Il exécute donc sans problème test_definer(),
qui lui affiche le contenu d'Adoption. Les privilèges vérifiés au niveau des instructions exécutées par la procédure sont en effet
ceux de l'utilisateur sdz, ayant défini celle-ci.
Préciser et modifier le définisseur
Les commandes de création des vues, triggers et procédures stockées permettent de préciser une clause DEFINER, dans
laquelle on précise l'identifiant d'un utilisateur.
Par défaut, c'est l'utilisateur courant qui est utilisé.
Cependant il est possible de donner un autre utilisateur comme définisseur de l'objet, à condition d'avoir le privilège global
SUPER. Sans ce privilège, on ne peut donner comme DEFINER que soi-même, soit avec CURRENT_USER ou
CURRENT_USER(), soit avec l'identifiant ('sdz'@'localhost' par exemple).
La clause DEFINER se place après le mot-clé CREATE.
Exemple : définition de deux procédures stockées avec l'utilisateur root (le seul ayant le privilège SUPER sur notre serveur), l'une
avec root pour DEFINER (CURRENT_USER()), l'autre avec john.
Code : SQL
DELIMITER |
CREATE DEFINER = CURRENT_USER() PROCEDURE test_definer2()
BEGIN
SELECT * FROM Race;
END |
CREATE DEFINER = 'john'@'localhost' PROCEDURE test_definer3()
BEGIN
SELECT * FROM Race;
END |
DELIMITER ;
Si l'on exécute ces deux procédures avec l'utilisateur john, on obtient deux résultats différents.
Code : SQL
CALL test_definer2();
CALL test_definer3();
La première procédure s'exécute sans problème. john n'a aucun droit sur la table Race, mais le définisseur de test_definer2()
étant root, ce sont ses privilèges qui comptent. Par contre, la seconde échoue, car le définisseur de test_definer3() a été initialisé
à john.
Modification du contexte
Il est possible, pour les vues et les procédures stockées, de changer la manière dont les privilèges sont vérifiés à l'exécution. On
peut faire en sorte que ce soit les privilèges de l'utilisateur qui se sert de la vue ou de la procédure ("l'invocateur") qui soient
vérifiés, et non plus les privilèges du définisseur.
Ce n'est pas possible pour les triggers, car ceux-ci ne sont pas exécutés directement par un utilisateur, mais par une action de
l'utilisateur (insertion, modification, suppression dans la table sur laquelle le trigger est défini).
Pour changer le contexte de vérification des privilèges d'une vue ou d'une procédure, il faut utiliser la clause SQL SECURITY
Partie 7 : Gestion des utilisateurs et configuration du serveur
389/414
www.openclassrooms.com
ERROR 1142 (42000): SELECT command denied to user 'john'@'localhost' for table 'adoption'
Par contre, john a le droit d'exécuter les procédures de la base de données elevage. Il exécute donc sans problème test_definer(),
qui lui affiche le contenu d'Adoption. Les privilèges vérifiés au niveau des instructions exécutées par la procédure sont en effet
ceux de l'utilisateur sdz, ayant défini celle-ci.
Préciser et modifier le définisseur
Les commandes de création des vues, triggers et procédures stockées permettent de préciser une clause DEFINER, dans
laquelle on précise l'identifiant d'un utilisateur.
Par défaut, c'est l'utilisateur courant qui est utilisé.
Cependant il est possible de donner un autre utilisateur comme définisseur de l'objet, à condition d'avoir le privilège global
SUPER. Sans ce privilège, on ne peut donner comme DEFINER que soi-même, soit avec CURRENT_USER ou
CURRENT_USER(), soit avec l'identifiant ('sdz'@'localhost' par exemple).
La clause DEFINER se place après le mot-clé CREATE.
Exemple : définition de deux procédures stockées avec l'utilisateur root (le seul ayant le privilège SUPER sur notre serveur), l'une
avec root pour DEFINER (CURRENT_USER()), l'autre avec john.
Code : SQL
DELIMITER |
CREATE DEFINER = CURRENT_USER() PROCEDURE test_definer2()
BEGIN
SELECT * FROM Race;
END |
CREATE DEFINER = 'john'@'localhost' PROCEDURE test_definer3()
BEGIN
SELECT * FROM Race;
END |
DELIMITER ;
Si l'on exécute ces deux procédures avec l'utilisateur john, on obtient deux résultats différents.
Code : SQL
CALL test_definer2();
CALL test_definer3();
La première procédure s'exécute sans problème. john n'a aucun droit sur la table Race, mais le définisseur de test_definer2()
étant root, ce sont ses privilèges qui comptent. Par contre, la seconde échoue, car le définisseur de test_definer3() a été initialisé
à john.
Modification du contexte
Il est possible, pour les vues et les procédures stockées, de changer la manière dont les privilèges sont vérifiés à l'exécution. On
peut faire en sorte que ce soit les privilèges de l'utilisateur qui se sert de la vue ou de la procédure ("l'invocateur") qui soient
vérifiés, et non plus les privilèges du définisseur.
Ce n'est pas possible pour les triggers, car ceux-ci ne sont pas exécutés directement par un utilisateur, mais par une action de
l'utilisateur (insertion, modification, suppression dans la table sur laquelle le trigger est défini).
Pour changer le contexte de vérification des privilèges d'une vue ou d'une procédure, il faut utiliser la clause SQL SECURITY
Partie 7 : Gestion des utilisateurs et configuration du serveur
389/414
www.openclassrooms.com