4 Administration du serveur

4.1 Configuration de MySQL

4.1.1 Options de ligne de commande de mysqld

Dans la plupart des cas, vous devrez modifier les options de mysqld dans le fichier d'options. See section 4.1.2 Fichier d'options `my.cnf'.

mysqld et mysqld.server lisent les options des groupes mysqld et server. mysqld_safe lit les options des groupes mysqld, server, mysqld_safe et safe_mysqld. Un serveur MySQL intégré lit généralement les options dans les groupes server, embedded et xxxxx_SERVER, où xxxxx est le nom de l'application.

mysqld accepte les options de ligne de commande suivantes :

--ansi

Utilise la syntaxe ANSI SQL au lieu de la syntaxe MySQL. See section 1.8.2 Exécuter MySQL en mode ANSI.

-b, --basedir=path

Chemin jusqu'au dossier d'installation. Tous les chemins sont généralement relatifs à celui-ci.

--big-tables

Autorise la sauvegarde de grands résultats dans des fichiers temporaires. Cela résout le problème des erreurs 'table full', mais ralentit les requêtes alors que des tables en mémoire suffirait. Depuis la version version 3.23.2, MySQL est capable de résoudre automatiquement ce problème en utilisant de la mémoire pour toutes les tables temporaires de petite taille, et en passant sur le disque au besoin.

--bind-address=IP

L'adresse IP à utiliser.

--character-sets-dir=path

Dossier contenant les jeux de caractères. See section 4.6.1 Le jeu de caractères utilisé pour les données et le stockage.

--chroot=path

Met le démon mysqld en environnement chroot au démarrage. Recommandé pour la sécurité. Cela limite les commandes LOAD DATA INFILE et SELECT ... INTO OUTFILE.

--core-file

Ecrire le fichier core lorsque mysqld s'arrête inopinéement. Pour certains fichiers, vous devez aussi spécifier --core-file-size à safe_mysqld. See section 4.7.2 safe_mysqld, le script père de mysqld. Notez que sur certains systèmes, comme Solaris, vous n'aurez pas de fichier de core si vous avez aussi utilisé l'option --user.

-h, --datadir=path

Chemin jusqu'au dossier des bases.

--debug[...]=

Si MySQL est configuré avec --with-debug, vous pouvez utiliser cette option pour obtenir un fichier de trace de ce que mysqld fait. See section D.1.2 Créer un fichier de traçage.

--default-character-set=charset

Spécifie le jeu de caractères par défaut. See section 4.6.1 Le jeu de caractères utilisé pour les données et le stockage.

--default-table-type=type

Spécifie le type de table par défaut. See section 7 Types de tables MySQL.

--delay-key-write[= OFF | ON | ALL]

Comment l'option des tables MyISAM DELAYED KEYS doit être utilisé. See section 5.5.2 Réglage des paramètres du serveur.

--delay-key-write-for-all-tables; En MySQL 4.0.3 vous devez utiliser --delay-key-write=ALL à la place.

Ne vide pas les buffers de clés entre deux écritures pour les tables MyISAM. See section 5.5.2 Réglage des paramètres du serveur.

--des-key-file=filename

Lit les clés par défaut utilisées par DES_ENCRYPT() et DES_DECRYPT() dans ce fichier.

--enable-external-locking (was --enable-locking)

Active le verrouillage système. Notez que si vous utilisez cette option sur un système pour qui lockd ne fonctionne pas (comme Linux), vous allez bloquer rapidement mysqld avec les verrous.

--enable-named-pipe

Active le support des tunnels nommés (seulement sur NT/Win2000/XP).

-T, --exit-info

Cette option est la combinaison d'options que vous pouvez utiliser pour le débogage du serveur mysqld; Si vous ne savez pas ce que ca fait exactement, ne les utilisez pas !

--flush

Ecrit toutes les données sur le disque après chaque requête SQL. Normalement, MySQL fait des écritures sur le disque après chaque requête, et laisse le système d'exploitation assurer la synchronisation avec le disque. See section A.4.1 Que faire si MySQL crashe constamment ?.

-?, --help

Affiche l'aide courte et termine le programme.

--init-file=file

Lit les commandes SQL dans ce fichier au démarrage.

-L, --language=...

Spécifie la langue utilisée pour les messages d'erreur du client. Le chemin complet doit être utilisé. See section 4.6.2 Langue des messages d'erreurs.

-l, --log[=file]

Enregistre les connexions et les requêtes dans ce fichier. See section 4.9.2 Le log général de requêtes.

--log-isam[=file]

Enregistre toutes les modifications des tables ISAM/MyISAM dans ce fichier (uniquement nécessaire pour déboguer ISAM/MyISAM).

--log-slow-queries[=file]

Enregistre toutes les requêtes qui ont pris plus de long_query_time secondes a s'exécute, dans ce fichier. See section 4.9.5 Le log des requêtes lentes.

--log-update[=file]

Enregistre les modifications dans le fichier file.# où # est un nombre unique si il n'est pas précisé. See section 4.9.3 Le log de modification.

--log-long-format

Enregistre des informations supplémentaires dans le fichier d'historique. Si vous utilisez l'option --log-slow-queries, alors les requêtes que vous qui n'utilisent pas les index sont enregistrées dans le log de requêtes longues.

--low-priority-updates

Les opérations de modifications de table (INSERT/DELETE/UPDATE) auront une priorité inférieure aux sélections. Cela peut être aussi fait via l'attribut {INSERT | REPLACE | UPDATE | DELETE} LOW_PRIORITY ... pour baisser la priorité d'une requête, ou avec SET LOW_PRIORITY_UPDATES=1 pour changer la priorité dans plus d'un thread. See section 5.3.2 Problème de verrouillage de tables.

--memlock

Verrouille le processus mysqld en mémoire. Cela fonctionne si votre système support la fonction mlockall() (comme Solaris). Ceci peut être utile si vous avez des problèmes avec le système d'exploitation qui force mysqld a utiliser le swap sur le disque.

--myisam-recover [=option[,option...]]]

Cette option est la combinaison de DEFAULT, BACKUP, FORCE et QUICK. Vous pouvez aussi lui donner la valeur explicite de "" si vous voulez désactiver cette option. Si cette option est utilisée, mysqld va vérifier si la table est marquée comme corrompue à l'ouverture de chaque table (cette dernière option ne fonctionne que si vous utilisez l'option --skip-external-locking). Si c'est le cas, mysqld va essayer de vérifier la table. Si la table était corrompue, mysqld essaie alors de la réparer. L'option suivante va affecter la manière avec la quelle la réparation s'effectue.

Option	Description
DEFAULT	Identique à ne pas donner d'option à --myisam-recover.
BACKUP	Si la table a été modifiée durant la réparation, sauver une copie du fichier `table_name.MYD', sous le nom de `table_name-datetime.BAK'.
FORCE	Exécute une réparation même si nous allons perdre une ou plusieurs lignes dans le fichier .MYD.
QUICK	Ne vérifie pas les lignes dans la table si il n'y a pas eu d'effacement.

Avant que la table ne soit automatiquement réparée, MySQL va ajouter une note dans le fichier de log d'erreurs. Si vous voulez être capable de restaurer la plupart des erreurs sans intervention de l'utilisateur, il vaut utiliser les options BACKUP,FORCE. Cela va forcer la réparation de la table, même si quelques lignes sont effacées, et conserve le vieux fichier de données comme sauvegarde, pour examen ultérieur.

--pid-file=path

Le chemin jusqu'au fichier de pid utilisé par safe_mysqld.

-P, --port=...

Numéro de port utilisé pour attendre les connexion TCP/IP.

-o, --old-protocol

Utilise le protocole 3.20, pour la compatibilité avec de très vieux clients. See section 2.5.6 Passer de la version 3.20 à la version 3.21.

--one-thread

Utilise uniquement un thread (pour débogage sous Linux). See section D.1 Déboguer un serveur MySQL.

-O, --set-variable var=option

Donne une valeur à une variable. --help liste ces variables. Vous pouvez trouver une description complète des variables dans la section sur la commande SHOW VARIABLES de ce manuel. See section 4.5.6.4 Syntaxe de SHOW VARIABLES. La section de paramétrage inclut des informations sur comment exploiter ces variables. Notez que --set-variable est obsolète depuis MySQL 4.0, utilisez simplement la syntaxe --var=option. See section 5.5.2 Réglage des paramètres du serveur. En MySQL 4.0.2, il est possible de changer une variable directement avec la syntaxe --variable-name=option et set-variable n'est plus nécessaire dans le fichier de configuration. Si vous voulez restreindre la valeur maximale que peut prendre une option via la commande SET, vous pouvez définir une limite en utilisant l'option de ligne de commande --maximum-variable-name. See section 5.5.6 Syntaxe de SET. Notez que lorsque vous donnez une valeur à une variable, MySQL peut corriger automatiquement votre valeur pour rester dans un intervalle donné, et ajuster un peu la valeur pour qu'elle soit optimale.

--safe-mode

Ignore certains étapes d'optimisation.

--safe-show-database

Avec cette option, la commande SHOW DATABASES retourne uniquemnt les bases pour lesquelles l'utilisateur a des droits. Depuis la version 4.0.2, cette option est abandonnée, et ne fait plus rien (l'option est activée par défaut) car nous avons désormais le droit de SHOW DATABASES. See section 4.3.1 Syntaxe de GRANT et REVOKE.

--safe-user-create

Si cette option est activée, un utilisateur ne peut pas créer de nouveaux utilisateurs avec la commande GRANT si l'utilisateur n'a pas les droits de INSERT dans la table mysql.user ou dans aucune colonne de cette table.

--skip-bdb

Désactive l'utilisation des tables BDB. Cela va économiser de la mémoire et accélérer le serveur un peu.

--skip-concurrent-insert

Désactive la possibilité de sélectionner et insérer en même temps dans les tables MyISAM (cela n'est utile que si vous pensez que vous avez trouvé un bug dans cette fonctionnalité).

--skip-delay-key-write; En MySQL 4.0.3, il est recommandé d'utiliser l'option

--delay-key-write=OFF à la place. Ignorez l'option DELAY_KEY_WRITE de toutes les tables. See section 5.5.2 Réglage des paramètres du serveur.

--skip-grant-tables

Cette option force le serveur à ne pas utiliser le système de privilège du tout. Cela donne à tous l'accès complet à toutes les bases de données ! Vous pouvez demander à un serveur en exécution d'utiliser à nouveau les tables de droits en exécutant la commande mysqladmin flush-privileges ou mysqladmin reload).

--skip-host-cache

Ne pas utiliser le cache de nom de domaine pour une résolution des IP plus rapide, mais interroger le serveur DNS à chaque connexion. See section 5.5.5 Comment MySQL utilise le DNS.

--skip-innodb

Désactive l'utilisation des tables InnoDB. Cela va économiser de la mémoire et accélérer le serveur un peu.

--skip-external-locking (ancien --skip-locking)

Ne pas utiliser le verrouillage du système. Pour utiliser les utilitaires isamchk ou myisamchk vous devez alors éteindre le système. See section 1.2.3 Jusqu'à quel point MySQL est il stable ?. Notez qu'en MySQL version 3.23 vous pouvez utiliser la commande REPAIR et CHECK pour réparer ou vérifier des tables MyISAM tables.

--skip-name-resolve

Les noms d'hôtes ne sont pas résolus. Toutes les colonnes Host dans vos tables de droits doivent être des IP numériques ou le mot localhost. See section 5.5.5 Comment MySQL utilise le DNS.

--skip-networking

Ne pas attendre les connexions TCP/IP du tout. Toutes les interactions du serveur mysqld seront faites avec les sockets Unix. Cette option est particulièrement recommandée pour les systèmes qui utilisent des requêtes locales. See section 5.5.5 Comment MySQL utilise le DNS.

--skip-new

Ne pas utiliser les nouvelles routines qui sont possiblement erronées.

--skip-symlink

Ne pas effacer ou renommer les fichiers qui ont un lien symbolique dans le dossier de données.

--skip-safemalloc

Si MySQL est configuré avec --with-debug=full, tous les programmes vérifieront la mémoire pour rechercher les écrasment de zone lors des allocations et libérations de mémoire. Comme ce test est lent, vous pouvez l'éviter, si vous n'avez pas besoin de tester la mémoire, en utilisant cette option.

--skip-show-database

Ne pas autoriser la commande SHOW DATABASES, a moins que l'utilisateur n'ait les droits de SHOW DATABASES. Depuis la version 4.0.2, vous n'avez plus besoin de cette option, car les droits pour ce faire sont distribués avec le droit de SHOW DATABASES.

--skip-stack-trace

Ne pas écrire les piles de traces. Cette option est pratique lorsque vous utilisez mysqld avec un débogueur. Sur certains systèmes, vous devez aussi utiliser cette option pour obtenir un fichier de core. See section D.1 Déboguer un serveur MySQL.

--skip-thread-priority

Désactive la priorisation des threads pour améliorer la vitesse de réponse.

--socket=path

Le fichier de socket à utiliser pour les connexions locales, au lieu du fichier par défaut /tmp/mysql.sock.

--sql-mode=option[,option[,option...]]

Cette option peut être la combinaison de : REAL_AS_FLOAT, PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, SERIALIZE et ONLY_FULL_GROUP_BY. Ellep peut aussi être vide ("") si vous voulez remettre cette option à 0. En spécifiant toutes les options ci-dessus, vous obtiendrez le même effet qu'avec l'option --ansi. Avec cette option, vous pouvez activer les modes SQL dont vous avez besoin. See section 1.8.2 Exécuter MySQL en mode ANSI.

--temp-pool

En utilisant cette option, vous allez réduire le jeu de noms qui sont utilisés lors de la création de fichier temporaires, plutôt qu'un nom unique à chaque fois. Ceci est un palliatif au noyau Linux qui crèe plusieurs fichiers nouveaux avec des noms différents. Avec l'ancien comportement, Linux semble 'perdre de la mémoire', car ils sont alloués au cache d'entrées du dossier au lieu de celui du disque.

--transaction-isolation= { READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE }

Configure le niveau d'isolation des transactions. See section 6.7.3 Syntaxe de SET TRANSACTION.

-t, --tmpdir=path

Chemin vers les fichiers temporaires. Il peut s'avérer pratique si votre dossier par défaut /tmp réside dans une partition qui est trop petite pour absorber les tables temporaires.

-u, --user= [user_name | userid]

Exécute le démon mysqld avec l'utilisateur user_name ou userid (numérique). Cette option est obligatoire lorsque vous démarrez mysqld en tant que root.

-V, --version

Affiche les informations de version.

-W, --log-warnings (Was --warnings)

Enregistre les alertes comme Aborted connection... dans le fichier `.err'. See section A.2.9 Erreurs de communication / Connexion annulée.

Il est possible de modifier la plupart des valeurs durant l'exécution, avec la commande SET command. See section 5.5.6 Syntaxe de SET.

4.1.2 Fichier d'options `my.cnf'

MySQL peut, depuis la version 3.22, lire des options de démarrage par défaut pour le serveur en ligne de commande, et, par le client, dans un fichier.

MySQL lit les options par défaut dans les fichiers suivants sous Unix :

Fichier	Objet
/etc/my.cnf	Options globales
DATADIR/my.cnf	Options spécifiques au serveur
defaults-extra-file	Le fichier spécifié par --defaults-extra-file=#
~/.my.cnf	Options spécifiques à l'utilisateur

DATADIR est le dossier de données de MySQL (typiquement `/usr/local/mysql/data' pour les installation binaires ou `/usr/local/var' pour une installation source). Notez que c'est ce dossier qui a été spécifié au moment de la configuration et non pas le dossier de l'option --datadir lorsque mysqld démarre ! (--datadir n'a aucun effet sur le serveur, car le serveur recherche les données avant de traiter les options de ligne de commande).

MySQL lit les fichiers d'options suivants sous Windows :

Notez que sous Windows, vous devez spécifier les chemins avec / plutôt que \. Si vous utilisez \, vous devez le spécifier deux fois, car \ est un caractère de protection pour MySQL.

MySQL essaie de lire les fichiers d'options dans l'ordre dans lequel ils sont présentés ci-dessus. Si des options sont spécifiées plusieurs fois, la dernière occurrence utilisée prend la préséeance sur les options spécifiées avant. Les options de ligne de commande ont la priorité sur les options spécifiées dans les fichiers. Certaines options peuvent être spécifiées en utilisant des variables d'environnement. Les options spécifiées en ligne de commande ou en fichier ont la priorité sur les options qui le sont via une variable d'environnement. See section E Variables d'environnement.

Les programmes suivants utilisent les fichiers d'options : mysql, mysqladmin, mysqld, mysqld_safe, mysql.server, mysqldump, mysqlimport, mysqlshow, mysqlcheck, myisamchk et myisampack.

Toute option longue qui doit être spécifiée en ligne de commande lorsque MySQL fonctionne, peut être aussi configurée dans le fichier d'options ( sans les doubles tirets). Exécutez le programme avec l'option --help pour avoir une liste des options disponibles.

Un fichier d'options contient des lignes ayant la forme suivante :

#comment

Les lignes de commentaires commencent avec `#' ou `;'. Les lignes vides sont ignorées.

[group]

group est le nom du programme ou du groupe pour lequel vous souhaitez configurer des options. Après une ligne de groupe, toutes les option et set-variable s'appliqueront au groupe nommé, jusqu'à la fin du fichier d'option ou du démarrage d'un autre groupe.

option

Ceci est équivalent à --option sur la ligne de commande.

option=value

Ceci est équivalent à --option=value sur la ligne de commande.

set-variable = variable=value

Ceci est équivalent à --set-variable variable=value sur la ligne de commande. Cette syntaxe doit être utilisée pour spécifier la valeur d'une variable mysqld. Notez que --set-variable est obsolète depuis MySQL 4.0, utilisez simplement --variable=value comme tel.

Le groupe client vous permet de spécifier des options qui ne s'appliquent qu'aux clients MySQL et non pas au serveur mysqld. C'est le groupe idéal pour spécifier des mots de passe de connexion au serveur (mais assurez-vous que vous êtes le seul à accéder à ce fichier !!).

Notez que pour les options et les valeurs, tous les caractères blancs de début et de fins seront automatiquement effacés. Vous pouvez utiliser les séquences d'échappement `\b', `\t', `\n', `\r', `\\' et `\s' dans votre chaîne à la place (`\s' == espace).

Voici un exemple typique de fichier d'options globales :

[client]
port=3306
socket=/tmp/mysql.sock

[mysqld]
port=3306
socket=/tmp/mysql.sock
set-variable = key_buffer_size=16M
set-variable = max_allowed_packet=1M

[mysqldump]
quick

Voici un exemple typique de fichier d'options utilisateur :

[client]
# Le mot de passe suivant va être utilisé avec le serveur
password=mon_mot_de_passe

[mysql]
no-auto-rehash
set-variable = connect_timeout=2

[mysqlhotcopy]
interactive-timeout

Si vous avez une distribution source, vous trouverez des exemples de configuration dans les fichiers nommés `my-xxxx.cnf' dans le dossier `support-files'. Si vous avez une distribution binaire, regardez dans le dossier `DIR/support-files', où DIR est le chemin de l'installation MySQL (typiquement `/usr/local/mysql'). Actuellement, il y a des exemples de configuration pour des systèmes petits, moyens, grands et très grands. Vous pouvez copier l'un des fichiers `my-xxxx.cnf' dans votre dossier utilisateur (renommez le fichier en `.my.cnf') pour le tester.

Tous les clients MySQL qui supportent les fichiers d'options, acceptent les options suivantes :

Notez que les options ci-dessus doivent être en ligne de commande pour être utilisées ! --print-defaults peut quand même être utilisé directement après la commande --defaults-xxx-file.

Note pour les développeurs : la gestion des fichiers d'options est implémentée simplement en traitant toutes les options qui correspondent (c'est à dire, toutes les options appropriées du groupe), avant les arguments de ligne de commande. Cela fonctionne bien pour les programmes qui utilisent la dernière occurrence comme valeur d'option, si elle est spécifiée plusieurs fois. Si vous avez un vieux programme qui traite les options multiples de cette façon mais ne lit pas les fichiers d'options, vous n'avez besoin que de deux lignes pour qu'il accepte cette fonctionnalité. Récupérez le code source de n'importe quel client MySQL standard pour voir comment le faire.

En scripts shell, vous pouvez utiliser la commande `my_print_defaults' pour analyser les fichiers de configuration :

shell> my_print_defaults client mysql
--port=3306
--socket=/tmp/mysql.sock
--no-auto-rehash

La ligne ci-dessus affiche toutes les options pour les groupes 'client' et 'mysql'.

4.1.3 Installer plusieurs serveurs sur la même machine

Dans certains cas, vous aurez besoin de plusieurs démons mysqld sur la même machine. Vous pouvez, par exemple, faire tourner une vieille version de MySQL pour la tester avec une nouvelle. Vous pouvez aussi donner des accès différents à des utilisateurs de différents serveurs mysqld, qu'il gèrent eux-mêmes.

Une méthode pour avoir plusieurs serveurs différents sur la même machine est de le configurer avec différents sockets et ports comme suit :

shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> scripts/mysql_install_db
shell> bin/safe_mysqld &

L'annexe sur les variables d'environnement inclut une liste des variables d'environnement que vous pouvez utiliser pour paramétrer mysqld. See section E Variables d'environnement.

La méthode ci-dessus est immédiate et peu propre pour ceux qui font des tests. Ce qui est bien avec cette méthode, c'est que les connexions que vous réalisez avec le shell ci-dessus seront automatiquement redirigées vers le serveur en fonctionnement.

Si vous avez besoin d'une méthode plus permanente, il est recommandé de créer un fichier d'options pour chaque serveur. See section 4.1.2 Fichier d'options `my.cnf'. Dans votre script de démarrage du serveur, vous pourriez spécifier tous les serveurs :

safe_mysqld --defaults-file=path-to-option-file

Enfin, les options suivantes doivent être différentes pour chaque serveur :

• port=#
• socket=path
• pid-file=path

Les options suivantes doivent être différentes, si elles sont utilisées :

• log=path
• log-bin=path
• log-update=path
• log-isam=path
• bdb-logdir=path

Si vous voulez plus de performances, vous pouvez aussi configurer différemment les options suivantes :

• tmpdir=path
• bdb-tmpdir=path

See section 4.1.1 Options de ligne de commande de mysqld.

Si vous installez une version binaire de MySQL (fichiers .tar) et que vous les démarrez avec ./bin/safe_mysqld, alors dans la plupart des cas, la seule option que vous devez modifier est la socket socket et le port port dans le script safe_mysqld.

See section 4.1.4 Faire fonctionner plusieurs serveurs MySQL sur la même machine.

4.1.4 Faire fonctionner plusieurs serveurs MySQL sur la même machine

Il y a des situations où vous souhaiterez avoir plusieurs serveurs MySQL sur la même machine. Par exemple, si vous voulez tester une nouvelle version du serveur avec votre configuration de production sans perturber votre installation de production. Ou bien, vous êtes un fournisseur de services Internet, et vous voulez fournir des installations distinctes pour des clients différents.

Si vous voulez exécuter plusieurs serveurs MySQL, le plus simple et de compiler les serveurs avec différents ports TCP/IP et fichiers de sockets pour qu'ils ne soient pas tous à l'écoute du même port ou de la même socket. See section 4.7.3 mysqld_multi, un programme pour gérer plusieurs serveurs MySQL.

Supposons que votre serveur est configuré avec le numéro de port par défaut, et le numéro de socket par défaut. Alors vous pouvez configurer le nouveau serveur avec la commande configure suivante :

shell> ./configure  --with-tcp-port=numero_port \
             --with-unix-socket-path=nom_fichier \
             --prefix=/usr/local/mysql-3.22.9

Ici, les options numero_port et nom_fichier doivent être différentes des valeurs par défaut, et avec l'option --prefix vous allez spécifier un autre dossier d'installation que celui qui est déjà utilisé par la première installation.

Vous pouvez vérifier le nom de la socket qui est utilisée par un serveur MySQL avec cette commande :

shell> mysqladmin -h hostname --port=numero_port variables

Notez que si vous spécifiez ``localhost'' comme nom d'hôte, mysqladmin va utiliser les sockets Unix plutôt que TCP/IP.

Si vous avez un serveur MySQL qui utilise déjà le port, vous obtiendrez une liste des variables de configuration les plus importantes de MySQL, y compris le nom de la socket.

Vous n'avez pas à recompiler un nouveau serveur MySQL juste pour le démarrer sous un autre port et une autre socket. Vous pouvez changer le port et la socket utilisée au moment du démarrage, avec safe_mysqld :

shell> /path/to/safe_mysqld --socket=nom_fichier --port=numero_port

mysqld_multi peut aussi prendre safe_mysqld (ou mysqld) comme argument, et passer les options depuis un fichier de configuration à safe_mysqld, et ainsi, à mysqld.

Si vous exécutez un nouveau serveur sur les mêmes données qu'un autre serveur, avec le log activé, vous devez spécifier le nom du fichier de log à safe_mysqld avec l'option --log, --log-update, ou --log-slow-queries. Sinon, les deux serveurs risquent d'écrire dans le même fichier de log.

Attention : normalement, vous ne devez pas avoir deux serveurs qui modifient en même temps les données dans les mêmes bases. Si votre OS ne supporte pas le verrouillage sans échec, cela peut vous mener à de déplaisantes surprises !

Si vous voulez utiliser un autre dossier de fichiers pour le second serveur, vous pouvez utiliser l'option --datadir=path de safe_mysqld.

Notez aussi que démarrer plusieurs serveurs MySQL (mysqlds) dans différentes machines, et les laisser accéder aux même données via NFS est généralement une mauvaise idée ! Le problème est que NFS va devenir un frein au niveau de la vitesse. Il n'est pas destiné à une telle utilisation. Et de plus, vous devrez trouver une solution pour vous assurer que deux des mysqld n'interfèrent pas entre eux. Actuellement, il n'y a pas de plate-forme qui soit 100% fiable pour le verrouillage de fichiers (le démon lockd), dans toutes les situations. Pourtant, il va y avoir un risque supplémentaire avec NFS ; cela rendra le travail encore plus compliqué pour le démon lockd. Alors, simplifiez-vous la vie, et oubliez cela. La solution efficace est d'avoir un ordinateur avec un système d'exploitation, qui gère efficacement les threads et a plusieurs processeurs.

Lorsque vous voulez vous connecter au serveur MySQL qui fonctionne avec un autre port que le port qui est compilé par défaut dans votre client, vous pouvez utiliser l'une des méthodes suivantes :

• Lancez le client avec l'option --host 'hostname' --port=numero_port pour vous connecter en TCP/IP, ou [--host localhost] --socket=nom_fichier pour vous connecter via une socket Unix.
• Dans vos programmes C ou Perl, vous pouvez indiquer le port ou la socket lors de la connexion au serveur MySQL.
• Si vous utilisez le code Perl avec le module DBD::mysql, vous pouvez lire les options des fichiers d'options MySQL. See section 4.1.2 Fichier d'options `my.cnf'.

  $dsn = "DBI:mysql:test;mysql_read_default_group=client;
          mysql_read_default_file=/usr/local/mysql/data/my.cnf"
  $dbh = DBI->connect($dsn, $user, $password);
  

• Modifiez les variables d'environnement MYSQL_UNIX_PORT et MYSQL_TCP_PORT pour qu'elles pointent sur la socket Unix et le port TCP/IP voulu avant de démarrer vos clients. Si vous utilisez une socket ou un port spécifique, il est recommandé de modifier ces variables dans votre fichier `.login'. See section E Variables d'environnement.
• Specifiez la socket et le port TCP/IP par défaut dans le fichier `my.cnf' de votre dossier personnel. See section 4.1.2 Fichier d'options `my.cnf'.

4.2 Règles de sécurité et droits d'accès au serveur MySQL

MySQL est pourvu d'un système avancé mais non standard de droits. Cette section décrit son fonctionnement.

4.2.1 Instructions générales de sécurité

Tous ceux qui utilisent MySQL avec un serveur connecté à l'internet doivent lire cette section, pour éviter les erreurs de sécurité les plus courantes.

En parlant de sécurité, nous mettons l'accent sur la nécessité de protéger la totalité du serveur (et non pas seulement le serveur MySQL), contre tous les types d'attaques possibles : cheval de troye, virus, dénis de services, écoute électronique. Nous ne couvrirons pas la totalité des aspects et des pannes ici.

MySQL utilise un système de sécurité basé sur les listes de contrôle d'accès (Access Control Lists; ACLs) pour toutes les connexions, requêtes et autres opérations qu'un utilisateur peut tenter d'exécuter. Il y a aussi le support des connexions chiffrées par mode SSL, entre le client et le serveur. De nombreux concepts sont présentés ici, et ne sont pas spécifiques à MySQL. Les mêmes concepts s'appliquent à de nombreuses applications.

Lorsque vous faîtes fonctionner MySQL, suivez ces règles le plus souvent possible :

• Ne jamais donner à quiconque (hormis l'utilisateur mysql root) l'accès à la table user dans la base mysql! Cette table est primordiale. Le mot de passe chiffré stocké dans la table est le véritable mot de passe MySQL. Quiconque connaît le mot de passe stocké dans la table user et a accès à la liste des hôtes d'un compte peut facilement se connecter avec cet utilisateur.
• Connaissez à fond le système de droits de MySQL. Les commandes GRANT et REVOKE sont utilisées pour contrôler les accès à MySQL. Ne donnez pas plus de droits que nécessaire. Ne donnez jamais des droits à tous les hôtes. Liste de points à vérifier :
  • Essayez mysql -u root. Si vous êtes capable de vous connecter avec succès au serveur sans qu'un mot de passe n'ai été demandé, vous avez un problème. Toute personne peut se connecter au serveur MySQL en tant qu'utilisateur root avec tous les droits ! Passez en revue votre installation MySQL, en faisant attention aux mots de passe root.
  • Utilisez la commande SHOW GRANTS et vérifiez qui a accès à quoi. Supprimez les droits qui ne sont pas nécessaires avec la commande REVOKE.
• Ne gardez par de mot de passe en clair dans vos tables. Lorsque votre ordinateur est infiltré, l'intrus pourra alors obtenir la liste complète des mots de passe, et les utiliser. Au lieu de cela, utilisez les fonctions MD5(), SHA1() ou une autre fonction de hash.
• Ne choisissez pas vos mots de passe dans un dictionnaire. Il y a des programmes spéciaux qui sont capable de les casser. Même des mots de passe comme ``xfish98'' sont très faibles. Bien meilleur est ``duag98'' qui contient aussi le mot ``fish'' mais tapé avec une touche à gauche sur le clavier standard QWERTY. Une autre méthode est d'utiliser ``Pfspeb'' qui est un mot créé à partir des premières lettres de la phrase ``Papa fume sa pipe en bois''. C'est un mot de passe facile à retenir, difficile à deviner pour une personne qui ne le connaît pas.
• Investissez dans un pare-feu. Cela vous protège de presque 50 % de tous les types de trous de sécurité des logiciels. Placez MySQL derrière un pare-feu, ou dans une zone démilitarisée (DMZ). Liste de points à vérifier :
  • Essayez de scanner vos ports depuis Internet, en utilisant des outils comme nmap. MySQL utilise le port 3306 par défaut. Ce port doit être inaccessible depuis des hôtes indus. Un autre moyen simple de tester si votre port MySQL est accessible ou pas, est d'essayer la commande suivante depuis une machine distante, où server_host est l'hôte de votre serveur MySQL :

    shell> telnet server_host 3306
    

    Si vous obtenez une connexion et des caractères étranges, c'est que le port est ouvert, et qu'il devrait être fermé par votre routeur ou votre pare-feu, à moins que vous n'ayez une bonne raison de le garder ouvert. Si telnet attend ou que la connexion est refusée, c'est que tout est bon : le port est bloqué.
• Ne faites jamais aucune confiance aux données des utilisateurs. Ils peuvent essayer de nombreux trucs pour vous envoyer du code spécial ou faire passer des séquences de caractères protégés via des formulaires web, ou n'importe quel outil que votre application utilise. Soyez certain que votre application reste sécurisée même si un utilisateur obtient du code comme ``; DROP DATABASE mysql;''. Ceci est un exemple extrême, mais de grosse fuites de données ou des pertes peuvent survenir si un pirate utilise des techniques similaires, et que vous n'êtes pas préparé pour. Vérifiez aussi toutes les données numériques. Une erreur commune est de protéger uniquement les chaînes. Certains pensent que si une base contient des données publiques, elle ne doit pas être protégée. C'est totalement faux. Au minimum, un attaque en dénis de service peut être pratiquée sur ces bases. Le plus simple moyen pour vous protéger contre ce type d'attaque est d'utiliser des apostrophes autour des constantes numériques : SELECT * FROM table WHERE ID='234' plutôt que SELECT * FROM table WHERE ID=234. MySQL convertit automatiquement la chaîne en nombre et supprime tous les caractères non numériques avant insertion. Point à vérifier :
  • Toutes les applications web :
    • Essayez d'entrer des guillemets `'' et `"' dans tous vos formulaires web. Si vous obtenez une erreur MySQL, alors étudiez le problème immédiatement.
    • Essayez de modifier toute URL dynamique en ajoutant les codes %22 (`"'), %23 (`#') et %27 (`'') dedans.
    • Essayez de modifier les types de données des URL dynamiques, de numérique en chaîne, grâce aux exemples ci-dessus. Votre application doit être sécurisée contre ce type d'attaques.
    • Essayez d'entrer des caractères comme des espaces ou des symboles spéciaux au lieu des nombres, dans les champs numériques. Votre application doit les supprimer avant de le passer à MySQL, ou votre application doit générer une erreur. Passer des valeurs non vérifiées à MySQL est très dangereux.
    • Vérifiez la taille des données avant de les passer à MySQL.
    • Donnez un autre nom d'utilisateur et un autre mot de passe à votre application que votre nom d'utilisateur d'administration. Ne donnez pas à votre application plus de droits que nécessaire.
  • Utilisateurs de PHP :
    • Etudiez la fonction addslashes(). Depuis PHP 4.0.3, la fonction mysql_escape_string() est disponible avec la même fonctionnalité que son alter ego en API MySQL C.
  • Utilisateurs de l'API MySQL C :
    • Vérifiez les appels à mysql_real_escape_string().
  • Utilisateurs de MySQL++ :
    • Vérifiez les options escape et quote des requêtes.
  • Utilisateurs Perl DBI :
    • Vérifiez la méthode quote() ou utilisez des variables liées.
  • Utilisateurs de Java JDBC :
    • Utilisez l'objet PreparedStatement et les variables liées.
• Ne transmettez aucunes données non chiffrées via Internet. Ces données peuvent être accessibles à quiconque a le temps et la capacité d'intercepter des données et de les utiliser pour son propre usage. Au lieu de cela, utilisez un protocole chiffré tel que SSL ou SSH. MySQL supporte les connexions SSL en interne, depuis la version 4.0.0. Le forward de port de SSH peut être utilisé pour créer un tunnel chiffré et compressé pour les communications.
• Apprenez à utiliser les utilitaires tcpdump et strings. Pour la plupart des cas, vous pouvez vérifier si les flux de données MySQL sont chiffrés en utilisant une commande telle que celle ci :

  shell> tcpdump -l -i eth0 -w - src or dst port 3306 | strings
  

  (Cela fonctionne sous Linux et devrait aussi fonctionner sous les autres systèmes avec de légères adaptations). Attention : si vous ne voyez pas de données, cela ne signifie pas que vous avez des données chiffrées. Si vous avez besoin de forte sécurité, vous devriez consulter un expert de la sécurité.

4.2.2 Comment protéger MySQL contre les pirates

Lorsque vous vous connectez à MySQL, vous devriez avoir besoin d'un mot de passe. Ce mot de passe n'est pas transmis en texte clair sur le réseau, mais comme l'algorithme de chiffrement n'est pas très fort, quelques efforts permettront à un pirate d'obtenir votre mot de passe s'il est capable de surveiller le trafic entre le client et le serveur. Si la connexion entre le client et le serveur utilise des réseaux non fiables, il est alors recommandé d'utiliser un tunnel SSH.

Toutes les autres informations sont transférées comme du texte clair, et quiconque surveille la connexion pourra les lire. Si vous souhaitez relever ce niveau de sécurité, il est recommandé d'utiliser le protocole compressé (avec les versions de MySQL 3.22 et plus récentes), pour compliquer considérablement le problème. Pour rendre la communication encore plus sûre, vous pouvez aussi utiliser ssh. Vous trouverez une version Open Source du client ssh sur le site http://www.openssh.org/, et une version commerciale du client ssh sur le site de http://www.ssh.com/. Avec eux, vous pouvez mettre en place une connexion TCP/IP chiffrée entre le serveur et le client MySQL.

Si vous utilisez MySQL 4.0, vous pouvez aussi utiliser le support OpenSSL interne. See section 4.3.9 Utilisation des connexions sécurisées.

Pour rendre le système MySQL encore plus sûr, nous vous recommandons de suivre les suggestions suivantes :

• Utilisez des mots de passe pour tous les utilisateurs MySQL. N'oubliez pas que tout le monde peut se connecter avec un nom d'utilisateur quelconque, simplement avec l'option mysql -u autre_utilisateur nom_de_base, si autre_utilisateur n'a pas de mot de passe. C'est un comportement classique pour les applications client/serveur que le client spécifie son nom d'utilisateur. Vous pouvez modifier les mots de passe de tous les utilisateurs en modifiant le script mysql_install_db avant de l'exécuter, ou vous pouvez modifier seulement le mot de passe du root MySQL comme ceci :

  shell> mysql -u root mysql
  mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe')
      ->             WHERE user='root';
  mysql> FLUSH PRIVILEGES;
  

• N'exécutez jamais le démon MySQL avec l'utilisateur Unix root. C'est très dangereux, car tout personne ayant le droit de FILE pour créer des fichiers au nom du root (par exemple, ~root/.bashrc). Pour éviter cela, mysqld refusera de s'exécuter au nom de root à moins que soit précisé l'option --user=root. mysqld peut être exécuté avec un utilisateur ordinaire sans droits particuliers. Vous pouvez aussi créer un utilisateur Unix mysql pour rendre cela encore plus sûr. Si vous exécutez mysqld sous un autre utilisateur Unix, vous n'avez pas à changer le mot de passe root dans la table user, car les noms d'utilisateurs MySQL n'ont rien à voir avec les noms d'utilisateurs Unix. Pour démarrer mysqld sous un autre nom d'utilisateur Unix, ajoutez la ligne user, qui spécifie le nom de l'utilisateur, dans le fichier d'options de [mysqld] `/etc/my.cnf' ou dans le fichier `my.cnf' présent dans le dossier de données du serveur. Par exemple :

  [mysqld]
  user=mysql
  

  Cette ligne va forcer le serveur à démarrer en tant qu'utilisateur mysql, même si vous démarrez le serveur manuellement ou avec les scripts safe_mysqld, ou mysql.server. Pour plus de détails, voyez section A.3.2 Comment exécuter MySQL comme un utilisateur normal.
• N'acceptez pas les liens symboliques pour les tables (cette fonctionnalité peut être désactivée avec l'option --skip-symlink option). Il est généralement important si vous exécutez mysqld en tant que root, car tout le monde aurait accès en écriture au dossier de données de MySQL, et pourrait alors effacer des fichiers systèmes. See section 5.6.1.2 Utiliser des liens symboliques avec les tables.
• Vérifiez que l'utilisateur Unix qui exécute mysqld est le seul utilisateur avec les droits de lecture et écriture dans le dossier de base de données.
• Ne donnez pas le droit de PROCESS à tous les utilisateurs. La liste fournie par mysqladmin processlist affiche le texte des requêtes actuellement exécutées, ce qui permet à toute personne pouvant exécuter cette commande de lire des valeurs qui seraient en clair, comme : UPDATE user SET password=PASSWORD('not_secure'). mysqld réserve une connexion supplémentaire pour les utilisateurs qui ont le droit de PROCESS, afin que le root MySQL puisse toujours se connecter et vérifier que tout fonctionne bien, même s'il ne reste plus de connexions libres pour les autres utilisateurs.
• Ne donnez pas le droit de FILE à tous les utilisateurs. Tout utilisateur qui possède ce droit peut écrire un fichier n'importe où sur le serveur, avec les droits hérités du démon mysqld ! Pour rendre cela plus sécuritaire, tous les fichiers générés par SELECT ... INTO OUTFILE sont lisibles par tous, mais personne ne peut les modifier. Le droit de FILE peut aussi être utilisé pour lire n'importe quel fichier accessible en lecture au démon qui fait tourner MySQL. Il devient donc possible, suivant les configurations, d'utiliser la commande LOAD DATA sur le fichier `/etc/passwd' pour tout mettre en table, et ensuite le relire avec la commande SELECT.
• Si vous ne faites pas confiance à votre DNS, vos pouvez simplement utiliser des adresses IP au lieu des noms d'hôtes. Dans ce cas, soyez très prudents lors de la création de droits qui utilisent des caractères joker.
• Si vous voulez restreindre le nombre de connexions d'un utilisateur, vous pouvez le faire en utilisant la variable max_user_connections de mysqld.

4.2.3 Options de démarrage qui concernent la sécurité

Les options suivantes de mysqld affectent la sécurité :

--local-infile[=(0|1)]

If one uses --local-infile=0 then one can't use LOAD DATA LOCAL INFILE.

--safe-show-database

Avec cette option, la commande SHOW DATABASES ne retourne que les bases pour lesquelles l'utilisateur courant a des droits. Depuis la verison 4.0.2, cette option est abandonnée, et ne sert plus à rien (elle est activée par défaut), car désormais, il y a le droit de SHOW DATABASES. See section 4.3.1 Syntaxe de GRANT et REVOKE.

--safe-user-create

Si cette option est activée, tout utilisateur ne peut créer d'autres utilisateurs avec les droits de GRANT, s'il ne dispose pas des droits d'insertion dans la table mysql.user. Si vous voulez donner un accès à un utilisateur pour qu'il puisse créer des utilisateurs avec les droits dont il dispose, vous pouvez lui donner les droits suivants :

mysql> GRANT INSERT(user) ON mysql.user TO 'user'@'hostname';

Cela va s'assurer que l'utilisateur ne peut par modifier une colonne directement, mais qu'il peut exécuter la commande GRANT sur d'autres utilisateurs.

--skip-grant-tables

Cette option force le serveur à ne pas utiliser les tables de droits. Cette option donne donc tous les droits à tout le monde sur le serveur ! Vous pouvez forcer un serveur en fonctionnement à reprendre les tables de droits en exécutant la commande mysqladmin flush-privileges ou mysqladmin reload.)

--skip-name-resolve

Les noms d'hôtes ne sont pas résolus. Toutes les valeurs de la colonne Host dans les tables de droits doivent être des adresses IP, ou bien localhost.

--skip-networking

Ne pas accepter les connexions TCP/IP venant du réseau. Toutes les connexions au serveur mysqld doivent être faîtes avec les sockets Unix. Cette option n'existe pas pour les versions antérieures à la 3.23.27, avec les MIT-pthread, car les sockets Unix n'étaient pas supportés par les MIT-pthreads à cette époque.

--skip-show-database

Ne pas autoriser la commande SHOW DATABASES, à moins que l'utilisateur n'ait les droits de SHOW DATABASES. Depuis la version 4.0.2, vous n'avez plus besoin de cette option, car les accès sont désormais donnés spécifiquement avec le droit SHOW DATABASES.

4.2.4 Problèmes de sécurité avec LOAD DATA LOCAL

Depuis MySQL 3.23.49 et MySQL 4.0.2, nous avons ajouté de nouvelles options pour traiter les problèmes de sécurité liés à LOAD DATA LOCAL.

Il existe deux problèmes particuliers pour le support de cette commande :

Comme la lecture du fichier est réalisée depuis le serveur, il est possible théoriquement de créer un serveur MySQL patché qui pourrait lire n'importe quel fichier sur la machine cliente, qui serait accessible à l'utilisateur.

Dans un environnement web, où les clients se connectent depuis un serveur web, un utilisateur peut se servir de la commande LOAD DATA LOCAL pour lire les fichiers qui sont sur le serveur web, et auquel ce dernier a accès (en supposant qu'un utilisateur peut exécuter n'importe quelle commande sur le serveur).

Il y a deux protections distinctes pour ces problèmes :

Si vous ne configurez pas MySQL avec l'option --enable-local-infile, alors LOAD DATA LOCAL sera désactivé par tous les clients, à moins que l'option mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) soit activée dans le client. See section 8.4.3.39 mysql_options().

Pour le client en ligne de commande mysql, LOAD DATA LOCAL peut être activé en spécifiant l'option --local-infile[=1], ou désactivé avec --local-infile=0.

Par défaut, tous les clients MySQL et les librairies sont compilés avec --enable-local-infile, pour être compatible avec MySQL 3.23.48 plus ancien.

Vous pouvez désactiver toutes les commandes LOAD DATA LOCAL du serveur MySQL en démarrant mysqld avec --local-infile=0.

Au cas où LOAD DATA LOCAL INFILE est désactivé sur le serveur ou le client, vous obtiendrez le message d'erreur (1148) :

The used command is not allowed with this MySQL version

4.2.5 Rôle du système de privilèges

La fonction première du système de privilèges de MySQL est d'authentifier les utilisateurs se connectant à partir d'un hôte donné, et de leur associer des privilèges sur une base de données comme SELECT, INSERT, UPDATE et DELETE.

Les fonctionnalités additionnelles permettent d'avoir un utilisateur anonyme et de contrôler les privilèges pour les fonctions spécifiques à MySQL comme LOAD DATA INFILE et les opérations administratives.

4.2.6 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.

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 :

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 :

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.

Pour les contrôles d'accès, les comparaisons de nom d'hôte avec la colonne Host sont insensibles à la casse. Les colonnes User, Password, Db et Table_name sont sensibles à la casse. Les valeurs de la colonne Column_name sont insensibles à la casse pour les versions de MySQL 3.22.12 et plus récent.

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 4.2.10 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.

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 :

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 tables db et host sont utilisées conjointement :
  • 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.
  • 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 4.2.10 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 4.3.3 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. Pour vous aider dans votre diagnostique, voyez section 4.2.11 Causes des erreurs Access denied. Pour des conseils sur les aspects sécurité, voyez section 4.2.2 Comment protéger MySQL contre les pirates.

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.

4.2.7 Droits fournis par MySQL

Les droits des utilisateurs sont stockés dans les tables user, db, host, tables_priv et columns_priv de la base mysql (c'est-à-dire, la base nommée mysql). Le serveur MySQL lit ces tables au démarrage, et dans les circonstances indiquées dans la section section 4.3.3 Quand les modifications de privilèges prennent-ils effets ?.

Les noms utilisés dans ce manuel font référence aux droits fournis par MySQL version 4.0.2, tel que présentés dans la table ci-dessous, avec le nom de la colonne associée au droit, dans la table de droits, et dans le contexte d'application :

Les droits de SELECT, INSERT, UPDATE et DELETE vous permettent de faire des opérations sur les lignes qui existent, dans une table existante d'une base.

La commande SELECT requiert le droit de SELECT uniquement si des lignes sont lues dans une une table. Vous pouvez exéctuer une commande SELECT même sans aucun droit d'accès à une base de données dans le serveur. Par exemple, vous pourriez utiliser le client mysql comme une simple calculatrice :

mysql> SELECT 1+1;
mysql> SELECT PI()*2;

Le droit de INDEX vous donne le droit de créer et détruire des index de table.

Le droit de ALTER vous donne le droit de modifier une table avec la commande ALTER TABLE.

Les droits de CREATE et DROP vous permettent de créer de nouvelles tables et bases de données, et de les supprimer.

Notez que si vous donnez le droit de DROP pour la base de données mysql à un utilisateur, cet utilisateur pourra détruire la base qui contient les droits d'accès du serveur !

Le droit de GRANT vous permet de donner les droits que vous possédez à d'autres utilisateurs.

Le droit de FILE vous donne la possibilité de lire et écrire des fichiers sur le serveur avec les commandes LOAD DATA INFILE et SELECT ... INTO OUTFILE. Tout utilisateur qui possède ce droit peut donc lire ou écrire dans n'importe quel fichier à l'intérieur duquel le serveur MySQL peut lire ou écrire.

Les autres droits sont utilisés pour les opérations administratives qui sont exécutées par l'utilitaire mysqladmin. La table ci-dessous montre quelle commande est associée à mysqladmin avec un de ces droits :

La commande reload indique au serveur de relire les tables de droits. La commande refresh vide les tables de la mémoire, écrit les données et ferme le fichier de log. flush-privileges est un synonyme de reload. Les autres commandes flush-* effectuent des fonctions similaires à la commande refresh mais sont plus limitées dans leur application, et sont préférables dans certains contextes. Par exemple, si vous souhaitez simplement vider les tampons dans le fichier de log, utilisez flush-logs, qui est un meilleur choix que refresh.

La commande shutdown éteint le serveur.

La commande processlist affiche les informations sur les threads qui s'exécutent sur le serveur. La commande kill termine un des threads du serveur. Vous pouvez toujours afficher et terminer vos propres threads, mais vous aurez besoin des droits de PROCESS pour afficher les threads, et le droit de SUPER pour terminer ceux qui ont été démarrés par d'autres utilisateurs. See section 4.5.5 Syntaxe de KILL.

C'est une bonne idée en général, de ne donner les droits de Grant qu'aux utilisateurs qui en ont besoin, et vous devriez être particulièrement vigilant pour donner certains droits :

• Le droit de GRANT permet aux utilisateurs de donner leurs droits à d'autres utilisateurs. Deux utilisateurs avec des droits différents et celui de GRANT pourront combiner leurs droits respectifs pour gagner un autre niveau d'utilisation du serveur.
• Le droit de ALTER peut être utilisé pour tromper le système en renommant les tables.
• Le droit de FILE peut servir à lire des fichiers accessibles à tous sur le serveur, et les placer dans une base de données. Le contenu pourra alors être lu et manipulé avec SELECT. Cela inclus le contenu de toutes les bases actuellement hébergées sur le serveur !
• Le droit de SHUTDOWN peut conduire au dénis de service, en arrêtant le serveur.
• Le droit de PROCESS permet de voir en texte clair les commandes qui s'exécutent actuellement, et notamment les changements de mot de passe.
• Les droits sur la base de données mysql peuvent être utilisés pour changer des mots de passe ou des droits dans la table des droits (Les mots de passe sont stockés chiffrés, ce qui évite que les intrus ne les lisent). S'ils accèdent à un mot de passe dans la table mysql.user, ils pourront l'utiliser pour se connecter au serveur avec cet utilisateur (avec des droits suffisants, le même utilisateur pourra alors remplacer un mot de passe par un autre).

Il y a des choses qui ne sont pas possibles avec le système de droits de MySQL :

• Vous ne pouvez pas explicitement interdire l'accès à un utilisateur spécifique. C'est à dire, vous ne pouvez pas explicitement décrire un utilisateur et lui refuser la connexion.
• Vous ne pouvez pas spécifier qu'un utilisateur a les droits de créer et de supprimer des tables dans une base, mais qu'il n'a pas les droits pour créer et supprimer cette base.

4.2.8 Se connecter au serveur MySQL

Les clients MySQL requièrent généralement que vous spécifiez les paramètres de connexion pour vous connecter au serveur MySQL : l'hôte que vous voulez utiliser, votre nom d'utilisateur et votre mot de passe. Par exemple, le client mysql peut être démarré comme ceci (les arguments optionnels sont entre crochets `[' et `]') :

shell> mysql [-h nom_d_hote] [-u nom_d_utilisateur] [-pvotre_mot_de_passe]

Les formes alternatives des options -h, -u, and -p sont --host=host_name, --user=user_name et --password=your_pass. Notez qu'il n'y a aucun espace entre l'option -p ou --password= et le mot de passe qui le suit.

Note : spécifier un mot de passe en ligne de commande n'est pas sécuritaire ! Tout utilisateur de votre serveur peut découvrir votre mot de passe en tapant la commande : ps auxww. See section 4.1.2 Fichier d'options `my.cnf'.

mysql utilise des valeurs par défaut pour chacun des paramètes qui manquent en ligne de commande :

• Le nom d'hôte par défaut est localhost.
• Le nom d'utilisateur par défaut est votre nom d'utilisateur de système Unix.
• Aucun mot de passe n'est transmis si -p manque.

Par exemple, pour un utilisateur Unix joe, les commandes suivantes sont équivalentes :

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

Les autres clients MySQL se comportent de manière similaire.

Sous Unix, vous pouvez spécifier différentes valeurs par défaut qui seront utilisées lorsque vous établierez la connexion, de manière à ce que vous n'ayez pas à entrer ces informations en ligne de commande lorsque vous invoquez un programme client. Cela peut se faire de plusieurs façons :

• Vous pouvez spécifier les informations de connexion dans la section [client] du fichier de configuration `.my.cnf' de votre dossier personnel. La section qui vous interesse ressemble à ceci :

  [client]
  host=nom_d_hote
  user=nom_d'utilisateur
  password=votre_mot_de_passe
  

  See section 4.1.2 Fichier d'options `my.cnf'.
• Vous pouvez spécifier les paramètres de connexion avec les variables d'environnement. L'hôte peut être spécifié à mysql avec la variable MYSQL_HOST. L'utilisateur MySQL peut être spécifié avec la variable USER (uniquement pour Windows). Le mot de passe peut être spécifié avec MYSQL_PWD : mais ceci est peu sécuritaire. Voir la prochaine section See section E Variables d'environnement.

4.2.9 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
• Votre mot de passe

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.
• Une valeur de '%' dans la colonne Host remplace n'importe quelle autre valeur.
• 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 prochain chapitre.
• 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.
  

  Dans l'exemple ci-dessus, toutes les IP dans l'intervalle 192.58.197.0 - 192.58.197.255 pourront se connecter au serveur MySQL.
• Les caractères joker ne sont pas autorisés dans le champ User, mais vous pouvez spécifier une valeur vide qui remplacera tous les noms. Si l'entrée de la table user, qui correspond à une connexion entrante, a un nom d'utilisateur vide, l'utilisateur est alors considéré comme anonyme (c'est l'utilisateur sans nom) et non pas le nom d'utilisateur fourni. Cela signifie qu'un utilisateur fournissant un nom d'utilisateur vide sera utilisé pour identifier ses droits dans les prochaines étapes.
• 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.

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

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. Par exemple, une connexion depuis thomas.loc.gov par fred sera identifiée de plusieurs façons différentes dans l'exemple ci-dessus. Comment le serveur va-t-il choisir si il y a plusieurs solutions ? Le serveur résoud cette question en triant les utilisateurs dans la colonne user après le démarrage, et il recherchera dans cette liste triée lorsqu'un utilisateur tente de se connecter. La première ligne qui satisfait les critères sera alors utilisée.

Le tri de la table user suit les règles suivantes. 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 avez des problèmes lors de la connexion, listez le contenu de la table user et triez-la à la main pour savoir quel est la première ligne qui est trouvée et utilisée.

Si la connexion s'est bien passée, mais que vos privilèges vous semblent faux, utilisez la fonction CURRENT_USER() (ajoutée en version 4.0.6) pour voir quel combinaison d'utilisateur/hôte votre connexion a utilisé. See section 6.3.6.2 Fonctions diverses.

4.2.10 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. See section 4.3.1 Syntaxe de GRANT et REVOKE. (Vous pouvez aussi vous reporter à la section section 4.2.6 Comment fonctionne le système de droits 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 :

1. 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.
2. 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.
3. 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.

4.2.11 Causes des erreurs Access denied

Si vous rencontrez des erreurs Access denied quand vous essayez de vous connecter au serveur MySQL, la liste suivante indique quelques actions à entreprendre pour corriger le problème :

• Après l'installation de MySQL, avez vous exécuté le script mysql_install_db pour initialiser le contenu de la table des droits ? Si tel n'est pas le cas, faites le. See section 4.3.4 Création des premiers droits MySQL. Testez les privilèges initiaux en exécutant la commande suivante :

  shell> mysql -u root test
  

  Le serveur devrait vous laisser vous connecter sans erreurs. Vous devez aussi vous assurer que vous avez un fichier `user.MYD' dans le dossier des bases de données MySQL. Ordinairement, il s'agit de `CHEMIN/var/mysql/user.MYD', où CHEMIN est le chemin vers le dossier racine de l'installation MySQL.
• Après une installation toute fraîche, vous devez vous connecter au serveur et créer les utilisateurs en réglant leurs permissions d'accès :

  shell> mysql -u root mysql
  

  Le serveur devrait vous laisser vous connecter car l'utilisateur root de MySQL n'a pas de mot de passe initial. Ceci est aussi une faille de sécurité, et donc, vous devez choisir un mot de passe pour l'utilisateur root en même tant que les autres utilisateurs MySQL. Si vous essayez de vous connecter en root et que vous rencontrez cette erreur :

  Access denied for user: '@unknown' to database mysql
  

  cela signifie que vous n'avez pas d'entrée dans la table user avec une valeur 'root' de la colonne User et que mysqld cne peut trouver de nom d'hôte à votre client. Dans ce cas, vous devez redémarrer le serveur avec l'option --skip-grant-tables et éditer le fichier `/etc/hosts' ou `\windows\hosts' pour ajouter une entrée pour votre hôte.
• Si vous obtenez une erreur qui ressemble à celle-ci :

  shell> mysqladmin -u root -pxxxx ver
  Access denied for user: 'root@localhost' (Using password: YES)
  

  Cela signifie que vous utilisez un mot de passe erroné. See section 4.3.7 Configurer les mots de passe. Si vous avez oublié le mot de passe root, vous pouvez redémarrer mysqld avec --skip-grant-tables pour changer le mot de passe. See section A.4.2 Comment réinitialiser un mot de passe Root oublié. Si vous obtenez l'erreur suivante même sans spécifier de mot de passe, cela signifie que vous avez un mauvais mot de passe dans un fichier my.ini. See section 4.1.2 Fichier d'options `my.cnf'. Vous pouvez ne pas utiliser les fichiers d'options en utilisant l'option --no-defaults, comme suit :

  shell> mysqladmin --no-defaults -u root ver
  

• Si vous mettez à jour une installation MySQL existante à partir d'une version plus ancienne que 3.22.11 vers la version 3.22.11 ou plus à jour, avez-vous exécuté le script mysql_fix_privilege_tables ? Si ce n'est pas le cas, faites le. La structure des tables de droits a changé avec la version 3.22.11 de MySQL lorsque la commande GRANT est devenue fonctionnelle.
• Si vos droits semblent avoir changé au milieu d'une session, il se peut qu'un super-utilisateur les ait changé. Recharger les tables de droits affecte les nouvelles connexions, mais affecte aussi les anciennes comme indiqué dans section 4.3.3 Quand les modifications de privilèges prennent-ils effets ?.
• Si vous n'arrivez pas à faire fonctionner votre mot de passe, souvenez-vous que vous devez utiliser la fonction PASSWORD() si vous le changez avec les commandes INSERT, UPDATE, ou SET PASSWORD. L'utilisation de la fonction PASSWORD() n'est pas nécessaire si vous spécifiez le mot de passe en utilisant la commande GRANT ... INDENTIFIED BY ou la commande mysqladmin password. See section 4.3.7 Configurer les mots de passe.
• localhost est un synonyme de votre nom d'hôte local, et est aussi l'hôte par défaut auquel le client essaye de se connecter si vous n'en spécifiez pas un explicitement. Toutefois, les connexions à localhost ne fonctionnent pas si vous utilisez une version antérieure à la 3.23.27 qui utilise les MIT-pthreads (les connexions à localhost sont réalisées en utilisant les sockets Unix, qui n'étaient pas supportés par les MIT-pthreads à ce moment). Pour contourner ce problème sur de tels systèmes, vous devez utiliser l'option --host pour nommer l'hôte du serveur explicitement. Cela créera une connexion TCP/IP vers le serveur mysqld. Dans ce cas, vous devez avoir votre vrai nom d'hôte dans les entrées de la table user du serveur hôte. (Cela est vrai même si vous utilisez un programme client sur la même machine que le serveur.)
• Si vous obtenez une erreur Access denied lorsque vous essayez de vous connecter à la base de données avec mysql -u nom_utilisateur nom_base, vous pouvez avoir un problème dans la table user. Vérifiez le en vous exécutant mysql -u root mysql et entrant la commande SQL suivante :

  mysql> SELECT * FROM user;
  

  Le résultat devrait comprendre une entrée avec les colonnes Host et User correspondate au nom d'hôte de votre ordinateur et votre nom d'utilisateur MySQL.
• Le message d'erreur Access denied vous dira en tant que qui vous essayez de vous identifier, l'hôte à partir duquel vous voulez le faire, et si vous utilisez ou pas un mot de passe. Normalement, vous devez avoir une entrée dans la table user qui correspondent au nom d'hôte et nom d'utilisateur donnés dans le message d'erreur. Par exemple, si vous obtenez une erreur qui contient Using password: NO, cela signifie que vous avez essayé de vous connecter sans mot de passe.
• Si vous obtenez l'erreur suivante en essayant de vous connecter à partir d'un hôte différenet de celui sur lequel est placé le serveur, c'est qu'il n'y a pas d'enregistrement dans la table user qui correspond à cet hôte :

  Host ... is not allowed to connect to this MySQL server
  

  Vous pouvez contourner le problème en utilisant l'outil en ligne de commande mysql (sur l'hôte du serveur !) pour ajouter un enregistrement aux tables user, db, ou host pour la combinaison utilisateur / nom d'hôte avec laquelle vous essayez de vous connecter puis exécuter mysqladmin flush-privileges. Si vous n'avez pas la version 3.22 de MySQL et que vous ne connaissez ni l'IP ni le nom d'hôte à partir duquel vous essayez de vous connecter, vous devez créer une entrée avec '%' dans la colonne Host dans la table user et redémarrer mysqld avec l'option --log sur la machine serveur. Après avoir essayé à nouveau de vous connecter à partir de la machine cliente, les informations contenues dans le log de MySQL vous apprendront comment vous vous êtes vraiment connectés. (Remplacez alors l'entrée de la table user contenant '%' avec le nom d'hôte qui apparait dans le log. Sinon, vous aurez un système non-sécurisé.) Une autre raison pour cette erreur sous Linux est que vous utilisez une version binaire de MySQL qui est compilée avec une version de glibc différente de celle que vous utilisez. Dans ce cas, vous devez soit mettre à jour votre système d'exploitation/glibc, soit télécharger les sources de MySQL et les compiler vous-même. Un RPM de sources est normalement facile à compiler et installer, cela ne devrait donc pas vous poser de gros problèmes.
• Si vous obtenez une erreur où le nom d'hôte est absent ou que celui-ci est une adresse IP alors que vous avez bien entré le nom d'hôte :

  shell> mysqladmin -u root -pxxxx -h some-hostname ver
  Access denied for user: 'root@' (Using password: YES)
  

  Cela signifie que MySQL a rencontré des erreurs lors de la résolution de l'IP du nom d'hôte. Dans ce cas, vous pouvez exécuter mysqladmin flush-hosts pour vider le cache interne des DNS. See section 5.5.5 Comment MySQL utilise le DNS. Les autres solutions sont :
  • Essayez de trouver le problème avec votre serveur DNS et corrigez le.
  • Spécifiez les IP à la place des noms d'hôtes dans les tables de droits de MySQL.
  • Démarrez mysqld avec --skip-name-resolve.
  • Démarrez mysqld avec --skip-host-cache.
  • Connectez vous à localhost si vous utilisez le serveur et le client sur la même machine.
  • Placez le nom de la machine cliente dans /etc/hosts.
• Si mysql -u root test fonctionne mais que mysql -h votre_hote -u root test provoque une erreur Access denied, il se peut que vous ayez entré de mauvaises informations pour votre nom d'hôte dans la table user. Un problème commun ici est que la valeur Host dans la table user spécifie un nom d'hôte non-qualifié, mais que vos routines système de résolution de noms retournent un nom de domaine pleinement qualifié (ou vice-versa). Par exemple, si vous avez une entrée avec l'hôte 'tcx' dans la table user, mais que vos DNS disent à MySQL que votre nom d'hôte est 'tcx.subnet.se', l'entrée ne fonctionnera pas. Essayez d'ajouter une entrée dans la table user qui contient votre adresse IP en tant que valeur de la colonne Host. (Une alternative est d'ajouter une entrée dans la table user avec une valeur de Host qui contient un caractère spécial, par exemple, 'tcx.%'. Toutefois, l'utilisation des noms d'hôtes se terminant par `%' est non-sécurisé et n'est pas recommendé !)
• Si mysql -u utilisateur test fonctionne mais que mysql -u utilisateur autre_base ne fonctionne pas, vous n'avez pas d'entrée pour autre_base listée dans la table db.
• Si mysql -u utilisateur nom_base fonctionne à partir du serveur, mais que mysql -h nom_hote -u utilisateur nom_base ne fonctionne pas à partir d'une autre machine, cette machine n'est pas listée dans la table user ou db.
• Si vous n'arrivez pas à trouver pourquoi vous obtenez l'erreur Access denied, effacez toutes les entrées de la table user dont la valeur du champ Host contiennent des caractères spéciaux (entrées contenant `%' ou `_'). Une erreur commune est d'insérer une nouvelle entrée avec Host='%' et User='un utilisateur', en pensant que cela vous permettra de spécifier localhost pour vous connecter à partir de la même machine. La raison pour laquelle cela ne fonctionnera pas est que les droits par défaut incluent une entrée avec Host='localhost' et User=''. Puisque cette entrée possède une valeur de <