6.8 Contrôle d'accès, étape 2 : vérification des requêtes

Une fois que la connexion est établie, le serveur passe en niveau 2. Pour chaque requête entrante, le serveur va vérifier que les droits sont suffisants pour effectuer la requête, en fonction du type d'opération. C'est ici qu'interviennent les champs de droits des tables de droits. Ces droits peuvent être stockés dans les tables user, db, host, tables_priv ou columns_priv tables. Ces tables sont gérées grce aux commandes GRANT et REVOKE. Reportez vous à la section Privileges, dans laquelle les champs de ces tables sont présentés).

Les droits pris en charge par la table user sont assignés globalement, et s'appliquent quelque soit la base de données courante. Par exemple, si la table user donne les droits de delete, vous pouvez efface n'importe quelle base de donnée sur le serveur ! ! En d'autres termes, la table user fourni les droits de super utilisateur, et il est avisé de ne donner ces droits qu'aux administrateurs du serveur. Pour les autres utilisateurs, il vaut mieux laisser les droits à 'N' et donner des droits spécifiques sur les bases de données, avec les tables db et host.

Les tables db et host donnent des droits spécifiques aux bases de données. Les valeurs acceptées dans les champs sont les suivantes :

• Les caractères spéciaux ``%'' et ``_'' peuvent être utilisés dans les champs Host et Db de deux tables.
• Un '%' dans le champs Host de la table db signifie ``tous les hôtes.'' Une valeur vide pour Host dans la table db signifie ``consulte la table host pour plus de détails.''
• Un '%' ou une chaîne vide dans le champs Host de la table host signifie `` tous les hôtes.''
• Un '%' ou une chaîne vide dans le champs Db dans l'une des tables signifie ``toutes les bases de données.''
• une chaîne vide dans le champs User dans l'une des tables corresponde à l'utilisateur anonyme.

Les tables db et host sont lues et triées au démarrage du serveur (en même temps que la table user). La table db est triée en fonction des champs Host, Db et User, et la table host table est triée en fonction des champs Host Db. Tout comme pour la table user, le trie met les valeurs les plus précises en premier, puis le plus larges. Lors de l'utilisation de la table, la première valeur qui correspond à l'utilisateur est utilisée.

Les tables de droits tables_priv et columns_priv contiennent les droits spécifiques aux droits par table et par colonne. Les valeurs des champs peuvent être les suivantes :

• Les caractères spéciaux ``%'' et ``_'' peuvent être utilisés dans les champs Host et Db de deux tables.
• Un '%' ou une chaîne vide dans le Host de la table db signifie ``tous les hôtes.''
• Les champs Db, Table_name et Column_name ne peuvent pas contenir de champs vide, ou de caractères spéciaux.

Les tables tables_priv et columns_priv sont triées en fonction des champs Host, Db et User. Le tri est identique à celui de la table db, mais étant donné que le champs Host ne contient pas de caractère spéciaux, le tri est nettement plus simple.

Le processus de vérification de requête est décrit ci-dessous. (Si vous êtes familier avec la programmation de contrôle d'accès, vous remarquerez que la description qui suit est un peu simplifiée, par rapport aux algorithmes utilisés. En fait, la description est équivalente au code, et la différence sert simplement à rendre la description plus accessible).

Pour les requêtes administratives telles que shutdown, reload, etc..., le serveur ne vérifie les droits que dans la table user, étant donné que c'est la seule qui spécifie les droits administratifs. La commande est exécutée si les droits sont disponibles, et sinon, la requête n'est pas autorisée. Par exemple, si vous voulez exécuter mysqladmin shutdown mais que votre compte utilisateur dans la table user n'a pas les droits de shutdown, l'autorisation n'est aps donnée, sans même vérifier les tables db ou host. (Etant donné que ces tables ne contiennent pas de colonne Shutdown_priv, il n'y a pas besoin de passer en revue ces tables.)

Pour les requêtes liées aux bases de données, telles que insert, update, etc., le serveur commence par vérifier les droits globaux (droits de super utilisateur) en recherchant dans la table user. Si il trouve des droits, l'exécution de la requête est autorisé. Si les droits globaux sont insuffisants, le serveur détermine les droits spécifiques à cette base en vérifiant les tables db et host:

1. Le serveur dans la table db une ligne qui corresponde à Host, Db et User de l'utilisateur. Host et User ont été défini lors de la connexion au serveur. Le champs Db prendre le nom de la base de données qui va être modifiée. Si il n'y a aucune entrée, l'autorisation n'est pas donnée.
2. Si il y a une ligne, et que le champs Host n'est pas laissé vide, cette ligne définit les droits de l'utilisateur, spécifiques à cette base.
3. Si le champs Host a été laissé vide, cela signifie que la table host contient la liste des hôtes qui ont l'autorisation d'accéder à cette base. Dans ce cas, une nouvelle recherche est effectuée dans la table host pour rechercher une ligne qui correspondent à Host et Db. Si aucune ligne n'est trouvée, alors l'accès n'est pas autorisé. Si une ligne est trouvée, les droits d'accès de cet utilisateur sont représentés par l'intersection des droits issus de la table db et de la table host, i.e., c'est à dire les droits qui sont à 'Y' dans les deux lignes trouvées. (De cette manière, vous pouvez donner des droits généraux, et restreindre sélectivement en fonction des hôtes, grce à la table host.)

Après avoir déterminé les droits spécifiques à la base de données, avec les tables db et host, le serveur les ajoutent aux droits globaux donnés par la table user. Si le résultat de cette union autorise l'opération, la requête est exécutée. Sinon, le serveur vérifie les droits sur les tables et les colonnes dans les tables tables_priv et columns_priv et les ajoutent aux droits de l'utilisateur. l'accès est alors donné ou retiré en fonction du résultat.

Exprimé par une formule booléenne, la description précédente du calcul des droits est la suivante :

global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges

Il n'est pas évident que si les droits globaux user sont insuffisants pour l'opération demandée, le serveur va les ajouter dans les différentes tables qui conservent les droits. La raison est qu'une requête peut nécessiter plusieurs droits différents. Par exemple, la commande INSERT ... SELECT requiert les droits d'insertion (insert) et de selection (select). Il se peut alors que les droits d'insertion soient disponible au niveau de la table, et que les droits de selection soient au niveau de la colonne. Dans ce cas, les droits de deux niveaux doivent être combinés pour autoriser la commande. D'où cette propagation de droits.

La table host est utilisée pour avoir une liste de serveurs ``sécurisés''. A TcX, la table host contenait la liste de toutes les machines du réseau local. Toutes ces machines avaient des autorisations d'accès sur le serveur.

Vous pouvez aussi utiliser cette table pour lister les serveurs qui ne sont pas sûrs. Par exemple, supposons que la machine public.votre.domaine soit située dans une zone publique qui ne soient pas sûre. Vous pouvez alors accepter tous les hôtes du réseau, et exclure cette machine, comme ceci :

+----------------------+----+-
| Host                 | Db | ...
+----------------------+----+-
| public.votre.domaine | %  | ... (tous les droits à 'N')
| %.your.domain        | %  | ... (tous les droits à 'Y')
+-------------------**-+----+-

Bien entendu, il est plus sage de tester toutes les lignes des tables de droits (e.g., en utilisant mysqlaccess) pour s'assurer que les droits sont bien donnés comme vous le souhaitez.