à 'joseph'@'localhost'.
Code : SQL
GRANT SELECT, UPDATE, INSERT, DELETE, GRANT OPTION
ON elevage.*
TO 'joseph'@'localhost' IDENTIFIED BY 'ploc4';
-- OU
GRANT SELECT, UPDATE, INSERT, DELETE
ON elevage.*
TO 'joseph'@'localhost' IDENTIFIED BY 'ploc4'
WITH GRANT OPTION;
Le privilège ALL doit s'utiliser tout seul. Il n'est donc pas possible d'accorder GRANT OPTION et ALL de la manière
suivante : GRANT ALL, GRANT OPTION… Il est nécessaire dans ce cas d'utiliser WITH GRANT OPTION.
Particularité des triggers, vues et procédures stockées
Les triggers, les vues et les procédures stockées (ainsi que les événements et les fonctions stockées, non couvertes par ce
cours) ont un système spécial quant à la vérification des privilèges des utilisateurs.
En effet, ces objets sont créés dans le but d'être exécutés dans le futur, et l'utilisateur créant un tel objet pourrait bien être
différent de l'utilisateur se servant de l'objet. Il y a donc deux types d'utilisateurs potentiels pour ces types d'objet : celui ayant
défini l'objet, et celui utilisant l'objet. Quels privilèges faut-il vérifier lorsqu'une procédure est exécutée ? Lorsque la requête
SELECT d'une vue est exécutée ?
Par défaut, ce sont les privilèges du définisseur (celui qui a défini l'objet) qui sont vérifiés. Ce qui veut dire qu'un utilisateur
pourrait exécuter une procédure agissant sur des tables sur lesquelles il n'a lui-même aucun privilège. L'important étant les
privilèges de l'utilisateur ayant défini la procédure. Bien entendu, un utilisateur doit toujours avoir le privilège EXECUTE pour
exécuter une procédure stockée, les privilèges du définisseur concernent les instructions à l'intérieur de la procédure ou du
trigger (ou de la requête SELECT pour une vue).
Exemple : avec l'utilisateur sdz, on définit une procédure faisant une requête SELECT sur la table Adoption. On exécute ensuite
cette procédure avec l'utilisateur john, qui n'a aucun droit sur la table Adoption.
Utilisateur sdz :
Code : SQL
USE elevage;
DELIMITER |
CREATE PROCEDURE test_definer()
BEGIN
SELECT * FROM Adoption;
END |
DELIMITER ;
Utilisateur john :
Code : SQL
USE elevage;
SELECT * FROM Adoption;
CALL test_definer();
L'utilisateur john n'a aucun droit sur Adoption. La requête SELECT échoue donc avec le message d'erreur suivant :
Partie 7 : Gestion des utilisateurs et configuration du serveur
388/414
www.openclassrooms.com
Code : SQL
GRANT SELECT, UPDATE, INSERT, DELETE, GRANT OPTION
ON elevage.*
TO 'joseph'@'localhost' IDENTIFIED BY 'ploc4';
-- OU
GRANT SELECT, UPDATE, INSERT, DELETE
ON elevage.*
TO 'joseph'@'localhost' IDENTIFIED BY 'ploc4'
WITH GRANT OPTION;
Le privilège ALL doit s'utiliser tout seul. Il n'est donc pas possible d'accorder GRANT OPTION et ALL de la manière
suivante : GRANT ALL, GRANT OPTION… Il est nécessaire dans ce cas d'utiliser WITH GRANT OPTION.
Particularité des triggers, vues et procédures stockées
Les triggers, les vues et les procédures stockées (ainsi que les événements et les fonctions stockées, non couvertes par ce
cours) ont un système spécial quant à la vérification des privilèges des utilisateurs.
En effet, ces objets sont créés dans le but d'être exécutés dans le futur, et l'utilisateur créant un tel objet pourrait bien être
différent de l'utilisateur se servant de l'objet. Il y a donc deux types d'utilisateurs potentiels pour ces types d'objet : celui ayant
défini l'objet, et celui utilisant l'objet. Quels privilèges faut-il vérifier lorsqu'une procédure est exécutée ? Lorsque la requête
SELECT d'une vue est exécutée ?
Par défaut, ce sont les privilèges du définisseur (celui qui a défini l'objet) qui sont vérifiés. Ce qui veut dire qu'un utilisateur
pourrait exécuter une procédure agissant sur des tables sur lesquelles il n'a lui-même aucun privilège. L'important étant les
privilèges de l'utilisateur ayant défini la procédure. Bien entendu, un utilisateur doit toujours avoir le privilège EXECUTE pour
exécuter une procédure stockée, les privilèges du définisseur concernent les instructions à l'intérieur de la procédure ou du
trigger (ou de la requête SELECT pour une vue).
Exemple : avec l'utilisateur sdz, on définit une procédure faisant une requête SELECT sur la table Adoption. On exécute ensuite
cette procédure avec l'utilisateur john, qui n'a aucun droit sur la table Adoption.
Utilisateur sdz :
Code : SQL
USE elevage;
DELIMITER |
CREATE PROCEDURE test_definer()
BEGIN
SELECT * FROM Adoption;
END |
DELIMITER ;
Utilisateur john :
Code : SQL
USE elevage;
SELECT * FROM Adoption;
CALL test_definer();
L'utilisateur john n'a aucun droit sur Adoption. La requête SELECT échoue donc avec le message d'erreur suivant :
Partie 7 : Gestion des utilisateurs et configuration du serveur
388/414
www.openclassrooms.com