Contrôle d'accès, étape 1 : Vérification de la connexion
<<<		 Contrôle d'accès, étape 2 : Vérification de la requête Quand les modifications de privilèges prennent-ils effets ?
>>>
5.4 Règles de sécurité et droits d'accès au serveur MySQL
5 Administration du serveur
 Manuel de Référence MySQL 4.1 : Version Française
. Rôle du système de privilèges
. Comment fonctionne le système de droits
. Droits fournis par MySQL
. Se connecter au serveur MySQL
. Contrôle d'accès, étape 1 : Vérification de la connexion
->Contrôle d'accès, étape 2 : Vérification de la requête
. Quand les modifications de privilèges prennent-ils effets ?
. Causes des erreurs Access denied
. Hashage de mots de passe en MySQL 4.1

5.4.6 Contrôle d'accès, étape 2 : Vérification de la requête

Une fois que vous avez établi la connexion, le serveur passe à l'étape 2. Pour chaque requête qui est fournie avec la connexion, le serveur vérifie si vous avez les droits suffisants pour exécuter une commande, en fonction du type de commande. C'est à ce moment que les colonnes de droits des tables d'administration entrent en scène. Ces droits peuvent provenir de la table user , db , host , tables_priv ou columns_priv . Les tables d'administration sont manipulées avec les commandes GRANT et REVOKE . (Vous pouvez aussi vous reporter à la section Comment le système de droits fonctionne qui liste les champs présents dans chaque table d'administration).

La table d'administration user donne les droits aux utilisateurs au niveau global, c'est à dire que ces droits s'appliquent quelle que soit la base de données courante. Par exemple, si la table user vous donne le droit d'effacement , DELETE , vous pouvez effacer des données dans n'importe quelle base de ce serveur. En d'autres termes, les droits stockés dans la table user sont des droits de super utilisateur. Il est recommandé de ne donner des droits via la table user uniquement aux super utilisateurs, ou aux administrateurs de bases. Pour les autres utilisateurs, il vaut mieux laisser les droits dans la table user à 'N' et donner des droits au niveau des bases uniquement, avec les tables db et host .

Les tables db et host donnent des droits au niveau des bases. Les droits peuvent être spécifiés dans ces tables comme ceci :
  • Les caractères '%' et '_' peuvent être utilisés dans la colonne Host et Db des deux tables. Si vous souhaitez utiliser le caractère '_' comme nom de base, utiliser la séquence '\_' dans la commande GRANT .
  • La valeur '%' dans la colonne Host de la table db signifie ``tous les hôtes''. Une valeur vide dans la colonne Host de la table db signifie ``consulte la table host pour plus de détails''.
  • La valeur '%' ou vide dans la colonne Host de la table host signifie ``tous les hôtes''.
  • La valeur '%' ou vide dans la colonne Db des deux tables signifie ``toutes les bases de données''.
  • Un utilisateur vide dans la colonne User de l'une des deux tables identifie l'utilisateur anonyme.
Les tables db et host sont lues et triées par le serveur au démarrage (en même temps que la table user . La table db est triée suivant les valeurs des colonnes Host , Db et User , et la table host est triée en fonction des valeurs des colonnes Host et Db . Comme pour la table user , le tri place les entrées les plus spécifiques au début, et les plus générales à la fin. Lorsque le serveur recherche une ligne, il utilise la première qu'il trouve.

Les tables tables_priv et columns_priv spécifient les droits au niveau des tables et des colonnes. Les valeurs des droits dans ces tables peuvent être spécifiés avec les caractères spéciaux suivants :

  • Les caractères '%' et '_' peuvent être utilisés dans la colonne Host des deux tables.
  • La valeur '%' dans la colonne Host des deux tables signifie ``tous les hôtes''.
  • Les colonnes Db , Table_name et Column_name ne peuvent pas contenir de valeur vide ou de caractères jokers, dans les deux tables.

Les tables tables_priv et columns_priv sont triées en fonction des colonnes Host , Db et User . Ce tri est similaire à celui du tri de la table db , même si le tri est bien plus simple, car seul le champ Host peut contenir des caractères jokers.

Le processus de vérification est décrit ci-dessous. Si vous êtes familier avec le code source de contrôle d'accès, vous noterez que la description diffère légèrement de l'algorithme utilisé. La description est équivalente à ce que fait en réalité le code. La différence permet une meilleure approche pédagogique.

Pour les requêtes d'administration comme SHUTDOWN , RELOAD , etc., le serveur vérifie uniquement l'entrée dans la table user , car c'est la seule table qui spécifie des droits d'administration. Le droit est donné si la ligne utilisée dans la connexion courante dans la table user donne le droit, et sinon, ce droit est interdit. Par exemple, si vous souhaitez exécuter la commande mysqladmin shutdown mais que votre ligne dans la table user ne vous en donne pas le droit ( SHUTDOWN ), vous n'aurez pas le droit sans même vérifier les tables db ou host : ces tables ne contiennent pas de colonne Shutdown_priv , ce qui évite qu'on en ait besoin.

Pour les requêtes exploitant une base de données, comme INSERT , UPDATE , etc., le serveur vérifie d'abord les droits globaux de l'utilisateur (droits de super utilisateur), en regardant dans la table user . Si la ligne utilisée dans cette table donne droit à cette opération, le droit est donné. Si les droits globaux dans user sont insuffisants, le serveur déterminera les droits spécifiques à la base avec les tables db et host :
  • Le serveur recherche dans la table db des informations en se basant sur les colonnes Host , Db et User . Les champs Host et User sont comparés avec les valeurs de l'hôte et de l'utilisateur qui sont connectés. Le champ Db est comparé avec le nom de la base de données que l'utilisateur souhaite utiliser. S'il n'existe pas de ligne qui corresponde à Host et User , l'accès est interdit.
  • S'il existe une ligne dans la table db et que la valeur de la colonne Host n'est pas vide, cette ligne définit les droits de l'utilisateur.
  • Si dans la ligne de la table db , la colonne Host est vide, cela signifie que la table host spécifie quels hôtes doivent être autorisés dans la base. Dans ce cas, une autre recherche est faite dans la table host pour trouver une ligne avec les colonnes Host et Db . Si aucune ligne de la table host n'est trouvée, l'accès est interdit. S'il y a une ligne, les droits de l'utilisateur sont calculés comme l'intersection ( NON PAS l'union !) des droits dans les tables db et host , c'est-à-dire que les droits doivent être marqués 'Y' dans les deux tables (de cette façon, vous pouvez donner des droits généraux dans la table db puis les restreindre sélectivement en fonction des hôtes, en utilisant la table host .
Après avoir déterminé les droits spécifiques à l'utilisateur pour une base grâce aux tables db et host , le serveur les ajoute aux droits globaux, donnés par la table user . Si le résultat autorise la commande demandée, l'accès est donné. Sinon, le serveur vérifie les droits au niveau de la table et de la colonne dans les tables tables_priv et columns_priv , et les ajoute aux droits déjà acquis. Les droits sont alors donnés ou révoqués en fonction de ces résultats.

Exprimée en termes booléens, la description précédente du calcul des droits peut être résumé comme ceci : 


droits globaux
OR (droits de base AND droits d'hôte)
OR droits de table
OR droits de colonne
Il n'est peut-être pas évident pourquoi, si les droits globaux issus de la table user sont initialement insuffisants pour l'opération demandée, le serveur ajoute ces droits à ceux de base, table ou colonne ? La raison est que la requête peut demander l'application de plusieurs droits. Par exemple, si vous exécutez une commande INSERT ... SELECT , vous aurez besoin des droits de INSERT et de SELECT . Vos droits peuvent être tels que la table user donne un droit, mais que la table db en donne un autre. Dans ce cas, vous aurez les droits nécessaires pour faire une opération, mais le serveur ne peut le déduire d'une seule table : les droits de plusieurs tables doivent être combinés pour arriver à la bonne conclusion.

La table host sert à gérer une liste d'hôtes reconnus et sécuritaires.

Chez TcX, la table host contient une liste de toutes les machines du réseau local. Ces machines reçoivent tous les droits.

Vous pouvez aussi utiliser la table host pour spécifier les hôtes qui ne sont pas sécuritaires. Supposons que la machine public.votre.domaine t est placée dans une zone publique que vous considérez comme peu sûre. Vous pouvez autoriser l'accès de toutes les machines, hormis celle-ci, grâce à la table host configurée comme ceci : 

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (tous les droits à 'N')
| %.your.domain      | %  | ... (tous les droits à 'Y')
+--------------------+----+-
Naturellement, vous devriez toujours tester vos requêtes dans la table de droits, en utilisant l'utilitaire mysqlaccess pour vous assurer que vous disposez des droits nécessaires pour réaliser cette opération.

<< Contrôle d'accès, étape 2 : Vérification de la requête >>
Contrôle d'accès, étape 1 : Vérification de la connexion Règles de sécurité et droits d'accès au serveur MySQL Quand les modifications de privilèges prennent-ils effets ?