6.6 Fonctionnement du système de droits

MySQL s'assure que tous les utilisateurs peuvent faire ce qu'ils ont le droit de faire. Lorsque vous vous connectez à un serveur MySQL, le serveur détermine votre identité grce à l'hôte depuis lequel vous vous connectez, et le nom d'utilisateur que vous spécifiez.. Le système vous alloue alors les droits adéquats.

MySQL considère que le nom de l'hôte et le nom d'utilisateur sont suffisants pour vous identifier sans ambiguïté, car il y a peu de chance qu'un nom d'utilisateur soit utilisé par la même personne, depuis tous les hôtes sur Internet ! Par exemple, l'utilisateur bill qui se connecte depuis whitehouse.gov ne sera probablement pas la même personne que l'utilisateur bill qui se connecte depuis microsoft.com. MySQL vous permet de distinguer les deux utilisateurs, et de donner des droits différents pour le même nom d'utilisateur, mais pour des hôtes différents.

MySQL contrôle l'accès en deux temps :

• Etape 1: le serveur vérifie que vous êtes autorisés à vous connecter.
• Etape 2: Si vous pouvez vous connecter, le serveur vérifie chaque requête que vous émettez pour voir sir vous avez des droits suffisants. Par exemple, pour sélectionner des lignes dans une table, ou effacer une table dans une base, le serveur s'assure que vous avez les droits de select ou de drop pour la base de données courante.

Le serveur utilise les tables user, db et host de la base mysql pour conserver les informations de connexion et les droits. Les champs de ces tables sont les suivants :

Pour la deuxième étape d'accès, le serveur peut consulter éventuellement (si la requête implique des tables)les tables tables_priv et columns_priv. Les champs de ces tables sont les suivants :

Chaque table de droits contient les champs d'identification et de droits.

Les champs d'identification détermine le contexte d'application des droits. Par exemple, la table user avec une ligne dont les champs Host, User ont les valeurs de 'thomas.loc.gov' et 'bob' seront utilisés pour identifier les connexions de bob depuis thomas.loc.gov. De la même façon, la table db avec une ligne dont les champs Host, User et Db sont respectivement 'thomas.loc.gov', 'bob' et 'reports' seront utilisés lors que bob se connecte depuis host thomas.loc.gov pour accéder à la base reports. Les tables tables_priv et columns_priv contiennent les noms des tables et des tables / colonnes pour qui s'appliquent les droits.

Pour des raisons de vérifications d'accès, les comparaisons effectuées sur les colonnes Host sont insensibles à la casse.. User, Password, Db et Table_name sont sensibles à la casse.. Column_name est insensible à la casse depuis MySQL 3.22.12.

Les champs de droits indiques quels droits sont donnés, quelles commandes sont autorisées. Le serveur combine les informations des différentes tables pour construire une fiche complète de description des droits du serveur. Les règles utilisées pour cela sont décrites dans la section 6.8 Contrôle d'accès, étape 2 : vérification des requêtes.

Les champs d'identification sont des chaînes, déclarées comme ci-dessous. La valeur par défaut de chaque champs est la chaîne vide.

Dans les tables user, db et host, tous les champs de droits sont déclarés comme des ENUM('N','Y') - chaque champs peut prendre la valeur 'N' ou 'Y', et la valeur par défaut est 'N'.

Dans les tables tables_priv et columns_priv, Les champs de droits sont déclarés comme des SET:

Présenté rapidement, le serveur utilises les tables de droits comme ceci :

• La table user détermine le droit de connexion. Pour les connexions autorisées, les droits globaux de l'utilisateurs sont précisés.
• Les tables db et host sont utilisées ensembles :
  • La table db détermine quelles bases sont accessibles à quels utilisateurs. Les champs de droits déterminent quels sont les droits autorisés.
  • La table host est utilisée comme une extension de db lorsque vous voulez qu'une ligne de db s'applique à plusieurs hôtes. Par exemple, si vous voulez qu'un utilisateur soit capable d'accéder à la base depuis plusieurs hôtes différents, laissez le champs Host de la table db vide, puis ajoutez un enregistrement dans la table host pour chaque hôte à autoriser. Ce mécanisme est décrit en détails dans la section 6.8 Contrôle d'accès, étape 2 : vérification des requêtes.
• Les tables tables_priv et columns_priv sont similaires à la table db, mais s'appliquent au niveau table et colonne, plutôt qu'au niveau base.

Notez bien que les droits administratifs (tels reload, shutdown, etc.) ne sont spécifiés que dans la tables user. En effet, les opérations administratives sont des opérations sur le serveur lui-même, et ne sont pas spécifiques à une base de données : il n'y a pas de raison d'avoir ces privilèges dans d'autres tables. En fait, seule la table user est consultée pour déterminer les droits administratifs.

Le droit file est spécifié seulement dans la table user. Ce n'est pas un droit administratif, mais il n'est pas dépendant de la table, ou de la base en cours.

Le serveur mysqld lit le contenu des tables de droits au démarrage. Les modifications des tables de droits ne prennent effets qu'à des moments précis, comme précisé dans la 6.9 Prise en compte des modifications de droits.

Lorsque vous modifiez le contenu des tables de droits, il es important de s'assurer que les modifications de droits produiront bien l'effet désiré. Il existe une aide pour comprendre ces erreurs, reportez vous à la section Security.

Un outil d'analyse pratique est le script mysqlaccess, qui est fournit gracieusement par Yves Carlier dans la distribution de MySQL. Lancez mysqlaccess avec l'option --help pour comprendre comment il fonctionne. Notez que mysqlaccess utilise les droits des tables user, db et host. Il ne prend pas en compte les droits sur les tables ou les colonnes.