Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06897.jsonl.gz/502

MySQL s'assure que tous les utilisateurs peuvent faire ce qu'ils ont le droit de faire. Lorsque vous vous connectez à un serveur MySQL, le serveur détermine votre identité grce à l'hôte depuis lequel vous vous connectez, et le nom d'utilisateur que vous spécifiez.. Le système vous alloue alors les droits adéquats.
MySQL considère que le nom de l'hôte et le nom d'utilisateur sont suffisants pour vous identifier sans ambiguïté, car il y a peu de chance qu'un nom d'utilisateur soit utilisé par la même personne, depuis tous les hôtes sur Internet ! Par exemple, l'utilisateur
bill qui se connecte depuis
whitehouse.gov ne sera probablement pas la même personne que l'utilisateur
bill qui se connecte depuis
microsoft.com. MySQL vous permet de distinguer les deux utilisateurs, et de donner des droits différents pour le même nom d'utilisateur, mais pour des hôtes différents.
MySQL contrôle l'accès en deux temps :
- Etape 1: le serveur vérifie que vous êtes autorisés à vous connecter.
- Etape 2: Si vous pouvez vous connecter, le serveur vérifie chaque requête que vous émettez pour voir sir vous avez des droits suffisants. Par exemple, pour sélectionner des lignes dans une table, ou effacer une table dans une base, le serveur s'assure que vous avez les droits de select ou de drop pour la base de données courante.
Le serveur utilise les tables
user,
db et
host de la base
mysql pour conserver les informations de connexion et les droits. Les champs de ces tables sont les suivants :
Pour la deuxième étape d'accès, le serveur peut consulter éventuellement (si la requête implique des tables)les tables
tables_priv et
columns_priv. Les champs de ces tables sont les suivants :
Chaque table de droits contient les champs d'identification et de droits.
Les champs d'identification détermine le contexte d'application des droits. Par exemple, la table
user avec une ligne dont les champs
Host,
User ont les valeurs de
'thomas.loc.gov' et
'bob' seront utilisés pour identifier les connexions de
bob depuis
thomas.loc.gov. De la même façon, la table
db avec une ligne dont les champs
Host,
User et
Db sont respectivement
'thomas.loc.gov',
'bob' et
'reports' seront utilisés lors que
bob se connecte depuis host
thomas.loc.gov pour accéder à la base
reports. Les tables
tables_priv et
columns_priv contiennent les noms des tables et des tables / colonnes pour qui s'appliquent les droits.
Pour des raisons de vérifications d'accès, les comparaisons effectuées sur les colonnes
Host sont insensibles à la casse..
User,
Password,
Db et
Table_name sont sensibles à la casse..
Column_name est insensible à la casse depuis MySQL 3.22.12.
Les champs de droits indiques quels droits sont donnés, quelles commandes sont autorisées. Le serveur combine les informations des différentes tables pour construire une fiche complète de description des droits du serveur. Les règles utilisées pour cela sont décrites dans la section 6.8 Contrôle d'accès, étape 2 : vérification des requêtes.
Les champs d'identification sont des chaînes, déclarées comme ci-dessous. La valeur par défaut de chaque champs est la chaîne vide.
Dans les tables
user,
db et
host, tous les champs de droits sont déclarés comme des
ENUM('N','Y') - chaque champs peut prendre la valeur
'N' ou
'Y', et la valeur par défaut est
'N'.
Dans les tables
tables_priv et
columns_priv, Les champs de droits sont déclarés comme des
SET:
Présenté rapidement, le serveur utilises les tables de droits comme ceci :
- La table
user détermine le droit de connexion. Pour les connexions autorisées, les droits globaux de l'utilisateurs sont précisés.
- Les tables
db et
host sont utilisées ensembles :
- La table
db détermine quelles bases sont accessibles à quels utilisateurs. Les champs de droits déterminent quels sont les droits autorisés.
- La table
host est utilisée comme une extension de
db lorsque vous voulez qu'une ligne de
db s'applique à plusieurs hôtes. Par exemple, si vous voulez qu'un utilisateur soit capable d'accéder à la base depuis plusieurs hôtes différents, laissez le champs
Host de la table
db vide, puis ajoutez un enregistrement dans la table
host pour chaque hôte à autoriser. Ce mécanisme est décrit en détails dans la section 6.8 Contrôle d'accès, étape 2 : vérification des requêtes.
- Les tables
tables_priv et
columns_priv sont similaires à la table
db, mais s'appliquent au niveau table et colonne, plutôt qu'au niveau base.
Notez bien que les droits administratifs (tels reload, shutdown, etc.) ne sont spécifiés que dans la tables
user. En effet, les opérations administratives sont des opérations sur le serveur lui-même, et ne sont pas spécifiques à une base de données : il n'y a pas de raison d'avoir ces privilèges dans d'autres tables. En fait, seule la table
user est consultée pour déterminer les droits administratifs.
Le droit file est spécifié seulement dans la table
user. Ce n'est pas un droit administratif, mais il n'est pas dépendant de la table, ou de la base en cours.
Le serveur
mysqld lit le contenu des tables de droits au démarrage. Les modifications des tables de droits ne prennent effets qu'à des moments précis, comme précisé dans la 6.9 Prise en compte des modifications de droits.
Lorsque vous modifiez le contenu des tables de droits, il es important de s'assurer que les modifications de droits produiront bien l'effet désiré. Il existe une aide pour comprendre ces erreurs, reportez vous à la section
Security.
Un outil d'analyse pratique est le script
mysqlaccess, qui est fournit gracieusement par Yves Carlier dans la distribution de MySQL. Lancez
mysqlaccess avec l'option
--help pour comprendre comment il fonctionne. Notez que
mysqlaccess utilise les droits des tables
user,
db et
host. Il ne prend pas en compte les droits sur les tables ou les colonnes.