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
>>>
5.5 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.5.5 Contrôle d'accès, étape 1 : Vérification de la connexion

Lorsque vous tentez de vous connecter au serveur MySQL, le serveur accepte ou rejette la connexion en fonction de votre identité et du mot de passe que vous fournissez. Si le mot de passe ne correspond pas à celui qui est en base, le serveur vous interdit complètement l'accès. Sinon, le serveur accepte votre connexion et passe à l'étape 2, et la gestion de commandes.

Votre identité est basée sur trois informations :

  • L'hôte depuis lequel vous vous connectez
  • Votre nom d'utilisateur MySQL

La vérification d'identité est réalisée avec les trois colonnes de la table user ( Host , User et Password ). Le serveur accepte la connexion uniquement si une entrée dans la table user correspond à votre hôte, et que vous fournissez le mot de passe qui correspond.

Les valeurs de la table user peuvent être paramétrées comme ceci :
  • Une valeur de la colonne Host peut être un nom d'hôte, une adresse IP numérique, ou encore 'localhost' , qui représente l'hôte local.
  • Vous pouvez utiliser les caractères jokers '%' et '_' dans le champ Host . Ces caractères ont la même valeur que pour les opérations de recherches avec l'opérateur LIKE . Par exemple, une valeur Host de '%' remplace n'importe quel nom d'hôte, alors que la valeur '%.mysql.com' représente tous les hôtes du domaine mysql.com .
  • Depuis MySQL version 3.23, les valeurs de Host spécifiées sous la forme d'IP numériques peuvent être complétées avec le masque de réseau qui indique combien de bits d'adresse sont utilisés. Par exemple : 
    
mysql> GRANT ALL PRIVILEGES ON db.*
        -> TO david@'192.58.197.0/255.255.255.0';
    Cela permet à toute personne se connectant depuis une adresse IP qui satisfait la contrainte suivante : 
    
user_ip & netmask = host_ip
    C'est à dire, pour la commande GRANT ci-dessus : 
    
client_ip & 255.255.255.0 = 192.58.197.0
    Les adresses IP qui satisfont cette condition et qui peuvent se connecter au serveur MySQL sont dans l'intervalle 192.58.197.0 à 192.58.197.255 .
  • Une valeur vide pour la colonne Host indique que les droits doivent être gérés avec les entrées de la table host qui correspond à l'hôte se connectant. Vous trouverez plus d'informations à ce sujet dans le chapitre Contrôle d'accès, étape 2 : vérification des requêtes .Une valeur vide dans la colonne Host des autres tables de droits revient à '%' .
Comme vous pouvez utiliser des jokers dans les valeurs IP de Host (par exemple, '144.155.166.%' pour tous les hôtes d'un sous-réseau), il est possible d'exploiter cette possibilité en appelant un hôte 144.155.166.ailleurs.com . Pour contrer ce type d'attaque, MySQL bloque les noms de domaines qui commence par des chiffres et des points. Par conséquent, si vous avez un hôte nommé 1.2.foo.com , il ne sera jamais accepté par la colonne Host des tables de droits. Un caractère joker d'adresse IP peut remplacer uniquement des nombres d'IP, et pas un nom d'hôte.

Dans la colonne User , les caractères joker ne sont pas autorisés, mais vous pouvez laisser cette valeur vide, qui acceptera tous les noms. Si la table user contient une connexion avec un nom d'utilisateur vide, l'utilisateur est considéré comme anonyme. Cela signifie que le nom d'utilisateur vide est utilisé pour les prochaines vérifications d'accès pour la durée de la connexion.

Le champ Password peut être vide. Cela ne signifie pas que n'importe quel mot de passe est valable, mais que l'utilisateur peut se connecter sans fournir de mot de passe.

Les valeurs non vides du champ Password représentent des valeurs du mot de passe chiffrées. MySQL ne stocke pas les mots de passe en clair, à la vue de tous. Au contraire, le mot de passe fourni pas l'utilisateur qui tente de se connecter est chiffré (avec la fonction PASSWORD() ). Le mot de passe ainsi chiffré est alors utilisé entre le client et le serveur pour vérifier s'il est valable. Cela évite que des mots de passe en clair circulent entre le client et le serveur, sur la connexion. Notez que du point de vue de MySQL, le mot de passe chiffré est le vrai mot de passe, ce qui fait que vous ne devez en aucun cas le donner à un tiers. En particulier, ne donnez pas accès en lecture aux utilisateurs normaux aux tables d'administration dans la base mysql ! A partir de sa version 4.1, MySQL utilise un mécanisme différent pour les logins, mots de passes qui est sécurisé même si les paquets TCP/IP sont sniffés et/ou que la base de données mysql est capturée.

Depuis la version 4.1, MySQL emploie une identification forte qui protège mieux les mots de passe durant le processus de connexion. Cette méthode est sécuritaire, même si les paquets TCP/IP sont surveillés pour que la base de données mysql est capturée. Le chiffrement est présenté dans la section Chiffrement des mots de passe en MySQL 4.1 .

Les exemples ci-dessous illustrent comment différentes variantes de Host et User dans la table user s'appliquent aux connexion entrantes :

Host value User value Connexions autorisées
'thomas.loc.gov' 'fred' fred , se connectant depuis thomas.loc.gov
'thomas.loc.gov' '' N'importe quel utilisateur, se connectant depuis thomas.loc.gov
'%' 'fred' fred , se connectant depuis n'importe quel hôte
'%' '' N'importe quel utilisateur, se connectant depuis n'importe quel hôte
'%.loc.gov' 'fred' fred , se connectant depuis n'importe quel hôte dans le domaine loc.gov
'x.y.%' 'fred' fred , se connectant depuis x.y.net , x.y.com , x.y.edu , etc. (Ceci n'est probablement pas très utilisé)
'144.155.166.177' 'fred' fred , se connectant depuis l'hôte d'IP 144.155.166.177
'144.155.166.%' 'fred' fred , se connectant depuis un hôte d'IP dans la classe C 144.155.166
'144.155.166.0/255.255.255.0' 'fred' Identique à l'exemple précédent

Comme vous pouvez utiliser des caractères jokers dans les adresses IP de la colonne Host (par exemple, '144.155.166.%' pour identifier tout un sous-réseau), il est possible d'exploiter cette fonctionnalité en nommant un hôte 144.155.166.kekpart.com . Pour contrer de telles tentatives, MySQL interdit les caractères jokers avec les noms d'hôtes qui commencent par des chiffres ou des points. Par exemple, si vous avez un nom d'hôte tel que 1.2.foo.com , il ne sera jamais trouvé dans la colonne Host des tables de droits. Seule une adresse IP numérique peut être comparée avec un masque à caractère joker.

Une connexion entrante peut être identifiée par plusieurs entrées dans la table user . MySQL résout ce problème comme ceci :
  • Lorsque le serveur lit la table user en mémoire, il trie les lignes.
  • Lorsqu'un client tente de se connecter, le serveur lit les lignes dans l'ordre.
  • Le serveur utilise la première ligne qui correspond au nom du client et à son nom d'utilisateur.

Supposons que votre table user ressemble à ceci : 


+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-
Lorsque le serveur lit cette table, il ordonne les lignes depuis les valeurs les plus spécialisées de la colonne Host jusqu'aux plus générales ( '%' dans la colonne Host signifie ``tous les hôtes'' et elle est la moins spécifique). Les entrées identiques dans la colonne Host sont ordonnées en fonction de la spécificité des valeurs de la colonne User (une entrée vide dans la colonne User signifie ``n'importe quel utilisateur'' et est spécifique). Le résultat de ce tri donne quelque chose comme ceci : 

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-
Lorsqu'une connexion est en cours de mise en place, le serveur regarde dans cette liste, et utilisera la première entrée trouvée. Pour une connexion depuis l'hôte localhost avec le nom d'utilisateur jeffrey , les entrées 'localhost' dans la colonne Host sont trouvées en premier. Parmi celles-la, la ligne avec un utilisateur vide satisfait les deux contraintes sur le nom et l'hôte. '%'/'jeffrey' pourrait avoir fonctionné, mais comme ce n'est pas le premier rencontré, il n'est pas utilisé.Voici un autre exemple. Supposons que la table user ressemble à ceci : 

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-
La table triée ressemble à ceci : 

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-
Une connexion depuis l'hôte thomas.loc.gov avec jeffrey satisfait les conditions de la première ligne, tandis qu'une connexion depuis whitehouse.gov avec jeffrey satisfait la seconde ligne.

Une erreur commune est de penser que pour un utilisateur donné, toutes les entrées qui utilisent explicitement ce nom seront utilisées en premier lorsque la connexion est en cours d'établissement. Ceci est tout simplement faux. L'exemple précédent illustre cette situation, car la connexion depuis l'hôte thomas.loc.gov avec jeffrey est la première ligne qui est trouvée, alors que la ligne contenant 'jeffrey' dans la colonne User est ignorée, car il n'y a pas de nom d'utilisateur.

Si vous arrivez à vous connecter au serveur, mais que les droits ne sont pas ce que vous attendez, vous vous êtes probablement identifié avec un autre compte. Pour savoir quel compte le serveur utilise lors de votre identification, utilisez la fonction CURRENT_USER() . Elle retourne la valeur au format user_name@host_name qui indique les valeurs des colonne User et Host de la table user qui vous est affectée. Supposons que jeffrey se connecte et utilise la requête suivante : 

mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost     |
+----------------+
Le résultat affiché ci-dessus indique que la ligne de la table user est l'utilisateur User vide. En d'autres termes, le serveur traite jeffrey comme un utilisateur anonyme.La fonction CURRENT_USER() est disponible depuis MySQL 4.0.6. Fonctions d'informations . Une autre piste à explorer : imprimez le contenu de la table user et triez la manuellement pour voir quelle est la première ligne qui est utilisée.
<< Contrôle d'accès, étape 1 : Vérification de la connexion >>
Se connecter au serveur MySQL Règles de sécurité et droits d'accès au serveur MySQL Contrôle d'accès, étape 2 : Vérification de la requête