Skip navigation links
5.5.3 Droits fournis par MySQL »
Section Navigation      [Toggle]

5.5.2. Comment fonctionne le système de droits

Le système de droits de MySQL s'assure que les utilisateurs font exactement ce qu'ils sont supposés pouvoir faire dans la base. Lorsque vous vous connectez au serveur, vous identité est déterminée par l'hôte d'où vous vous connectez et le nom d'utilisateur que vous spécifiez. Le système donne les droits en fonction de votre identité et de ce que vous voulez faire.

MySQL considère votre nom d'hôte et d'utilisateur pour vous identifier, car il n'y pas que peu de raisons de supposer que le même nom d'utilisateur appartient à la même personne, quelque soit son point de connexion sur Internet. Par exemple, l'utilisateur joe qui se connecte depuis office.com n'est pas forcément la même personne que joe qui se connecte depuis elsewhere.com. MySQL gère cela en vous aidant à distinguer les différents utilisateurs et hôtes qui ont le même nom : vous pourriez donner des droits à joe lorsqu'il utilise sa connexion depuis office.com, et un autre jeu de droits lorsqu'il se connecte depuis elsewhere.com.

Le contrôle d'accès de MySQL se fait en deux étapes :

  • Etape 1 : Le serveur vérifie que vous êtes autorisé à vous connecter.

  • Etape 2 : En supposant que vous pouvez vous connecter, le serveur vérifie chaque requête que vous soumettez, pour vérifier si vous avez les droits suffisants pour l'exécuter. Par exemple, si vous sélectionnez des droits dans une table, ou effacez une table, le serveur s'assure que vous avez les droits de SELECT pour cette table, ou les droits de DROP, respectivement.

Si vos droits ont changé (par vous-mêmes ou bien par un administrateur), durant votre connexion, ces changements ne prendront peut être effets qu'à la prochaine requête. Voyez la section Section 5.5.7, « Quand les modifications de privilèges prennent-ils effets ? » pour plus détails.

Le serveur stocker les droits dans des tables de droits, situées dans la base mysql. Le serveur lit le contenu de ces tables en mémoire lorsqu'il démarre, et les relit dans différentes circonstances, détaillées dans Section 5.5.7, « Quand les modifications de privilèges prennent-ils effets ? ». Le contrôle d'accès se fait par rapport aux tables en mémoire.

Normalement, vous manipulez le contenu des tables indirectement, via les commandes GRANT et REVOKE pour configurer des comptes et des droits. See Section 13.5.1.3, « Syntaxe de GRANT et REVOKE ». La discussion de cette section décrit la structure des tables de droits, et comment elle interagit avec les clients.

Le serveur utilise les tables user, db et host dans la base mysql durant les deux étapes. Les champs de cette table sont les suivants :

Table name utilisateur base hôte
Scope fields Host Host Host
  User Db Db
  Password User  
Privilege fields Select_priv Select_priv Select_priv
  Insert_priv Insert_priv Insert_priv
  Update_priv Update_priv Update_priv
  Delete_priv Delete_priv Delete_priv
  Index_priv Index_priv Index_priv
  Alter_priv Alter_priv Alter_priv
  Create_priv Create_priv Create_priv
  Drop_priv Drop_priv Drop_priv
  Grant_priv Grant_priv Grant_priv
  References_priv References_priv References_priv
  Reload_priv    
  Shutdown_priv    
  Process_priv    
  File_priv    
  Show_db_priv    
  Super_priv    
  Create_tmp_table_priv Create_tmp_table_priv Create_tmp_table_priv
  Lock_tables_priv Lock_tables_priv Lock_tables_priv
  Execute_priv    
  Repl_slave_priv    
  Repl_client_priv    
  ssl_type    
  ssl_cypher    
  x509_issuer    
  x509_cubject    
  max_questions    
  max_updates    
  max_connections    

Lors de la seconde étape du contrôle d'accès (vérification de la requête), le serveur peut, suivant la requête, consulter aussi les tables tables_priv et columns_priv. Les champs de ces tables sont :

Nom de la table tables_priv columns_priv
Champ Host Host
  Db Db
  User User
  Table_name Table_name
    Column_name
Droit Table_priv Column_priv
  Column_priv  
Autre champ Timestamp Timestamp
  Grantor  

Chaque table de droit contient des champs d'identification et des champs de droits.

  • Les champs d'identification déterminent quels utilisateurs correspondent à cette ligne dans la table. Par exemple, une ligne dans la table user avec les valeurs dans les colonnes Host et User de 'thomas.loc.gov' et 'bob' servira à identifier les connexions qui sont faites par l'utilisateur bob depuis l'hôte thomas.loc.gov. De même, une ligne dans la table db avec les valeurs des colonnes Host, User et Db de 'thomas.loc.gov', 'bob' et 'reports' sera utilisée lorsque l'utilisateur bob se connecte depuis l'hôte thomas.loc.gov pour accéder à la base reports. Les tables tables_priv et columns_priv contiennent en plus des champs indiquant les tables et combinaisons tables et colonnes auxquelles les lignes s'appliquent.

  • Les champs de droits indiquent si le droit est donné, c'est à dire si l'opération indiquée peut être exécuté. Le serveur combine les informations dans différentes tables pour former une description complète de l'utilisateur. Les règles utilisées sont décrites dans Section 5.5.6, « Contrôle d'accès, étape 2 : Vérification de la requête ».

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

Nom de la colonne Type
Host CHAR(60)
User CHAR(16)
Password CHAR(16)
Db CHAR(64)
Table_name CHAR(60)
Column_name CHAR(60)

Avant MySQL 3.23, la colonne Db valait CHAR(32) dans certaines tables, et CHAR(60) dans d'autres.

Pour vérifier les accès, la comparaison sur les valeurs de la colonne Host sont sensibles à la casse. User, Password, Db et Table_name sont insensibles. Les valeurs de Column_name sont insensibles depuis MySQL 3.22.12.

Dans les tables user, db et host, tous les champs de droits sont déclarés avec le type ENUM('N','Y') : il peuvent prendre tous les valeurs de 'N' (non) ou 'Y' (oui, YES), 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 champs de type SET :

Nom de la table Nom du champs Valeurs possibles
tables_priv Table_priv 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
tables_priv Column_priv 'Select', 'Insert', 'Update', 'References'
columns_priv Column_priv 'Select', 'Insert', 'Update', 'References'

En bref, le serveur utilise les tables de droits comme ceci :

  • La table user détermine si le serveur accepte ou rejette la connexion. Pour les connexions acceptées, tous les privilèges donnés dans la table user indiquent des privilèges globaux. Ces droits d'appliquent à toutes les bases du serveur.

  • Les champs d'identification de la table db déterminent quels utilisateurs peuvent accéder à quelles bases, depuis quel hôte. Les champs de droits indiquent alors les opérations permises. Les droits s'appliquent alors à toutes les bases sur le serveur.

  • La table host est utilisée comme extension de la table db lorsque vous voulez qu'une ligne de la table db s'applique à plusieurs hôtes. Par exemple, si vous voulez qu'un utilisateur soit capable d'utiliser une base depuis plusieurs hôtes dans votre réseau, laissez la colonne Host vide dans la table db, Ce mécanisme est décrit en détails dans Section 5.5.6, « Contrôle d'accès, étape 2 : Vérification de la requête ».

  • Les tables tables_priv et columns_priv sont similaires à la table db, mais sont plus atomiques : elle s'appliquent au niveau des tables et des colonnes, plutôt qu'au niveau des bases.

Notez que les droits d'administration tels que (RELOAD, SHUTDOWN, etc...) ne sont spécifiés que dans la table user. En effet, ces opérations sont des opérations au niveau serveur, et ne sont pas liées à une base de données, ce qui fait qu'il n'y a pas de raison de les lier avec les autres tables. En fait user doit être consulté pour déterminer les autorisations d'administration.

Le droit de FILE est spécifié par la table user. Ce n'est pas un droit d'administration, mais votre capacité à lire ou écrire des fichiers sur le serveur hôte et dépendant de la base à laquelle vous accédez.

Le serveur mysqld lit le contenu des tables de droits une fois, au démarrage. Lorsqu'il y a des modifications dans les tables, elles prennent effet tel qu'indiqué dans Section 5.5.7, « Quand les modifications de privilèges prennent-ils effets ? ».

Lorsque vous modifiez le contenu des tables de droits, c'est une bonne idée que de s'assurer que vous avez bien configuré les droits qui vous intéressent. Un moyen de vérifier les droits pour un compte est d'utiliser la commande SHOW GRANTS. Par exemple, pour déterminer les droits qui sont donnés à un compte avec les valeurs Host et User de pc84.example.com et bob, utilisez cette commande : 

mysql> SHOW GRANTS FOR 'bob'@'pc84.example.com';

Un outil de diagnostique pratique est le script mysqlaccess, que Yves Carlier a fourni à la distribution MySQL. Appelez mysqlaccess avec l'option the --help pour comprendre comment il fonctionne. Notez que mysqlaccess ne vérifie les accès que pour les tables user, db et host. Il n'utilise pas les tables de droit de niveau table ou colonne.

Pour plus d'aide au diagnostique pour les problèmes de droits, voyez la section Section 5.5.8, « Causes des erreurs Access denied ». Pour des conseils généraux sur la sécurité, voyez la section Section 5.4, « Sécurité générale du serveur ».

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.