5.4 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.4.2 Comment fonctionne le système de droits
Le système de droits de MySQL s'assure que les utilisateurs font exactement
ce qu'ils sont supposés pouvoir faire dans la base. Lorsque vous vous connectez
au serveur, vous identité est déterminée par
l'hôte d'où vous vous connectez
et
le nom d'utilisateur que vous spécifiez
. Le système
donne les droits en fonction de votre identité et de
ce que vous voulez faire
.
MySQL considère votre nom d'hôte et d'utilisateur pour vous identifier,
car il n'y pas que peu de raisons de supposer que le même nom d'utilisateur
appartient à la même personne, quelque soit son point de connexion sur
Internet. Par exemple, l'utilisateur
joe
qui se connecte depuis
office.com
n'est pas forcément la même personne que
joe
qui se connecte depuis
elsewhere.com
. MySQL gère cela en vous aidant à distinguer les différents
utilisateurs et hôtes qui ont le même nom : vous pourriez donner des droits à
joe
lorsqu'il utilise sa connexion depuis
office.com
, et un autre
jeu de droits lorsqu'il se connecte depuis
elsewhere.com
.
Le contrôle d'accès de MySQL se fait en deux étapes :
-
Etape 1 : Le serveur vérifie que vous êtes autorisé à vous connecter.
-
Etape 2 : En supposant que vous pouvez vous connecter, le serveur vérifie
chaque requête que vous soumettez, pour vérifier si vous avez les droits
suffisants pour l'exécuter. Par exemple, si vous sélectionnez des droits
dans une table, ou effacez une table, le serveur s'assure que vous
avez les droits de
SELECT
pour cette table, ou les droits de
DROP
, respectivement.
Si vos droits ont changé (par vous-mêmes ou bien par un administrateur),
durant votre connexion, ces changements ne prendront peut être effets qu'à la prochaine
requête. Voyez la section Quand est-ce que les droits prennent effets pour plus détails.
Le serveur stocker les droits dans des tables de droits, situées dans la
base
mysql
. Le serveur lit le contenu de ces tables en mémoire lorsqu'il
démarre, et les relit dans différentes circonstances, détaillées dans
Quand est-ce que les droits prennent effets . Le contrôle d'accès se fait par rapport aux tables
en mémoire.
Normalement, vous manipulez le contenu des tables indirectement, via les commandes
GRANT
et
REVOKE
pour configurer des comptes et des droits.
Syntaxe de
GRANT
et
REVOKE
.
La discussion de cette section décrit la structure des tables de droits, et comment
elle interagit avec les clients.
Le serveur utilise les tables
user
,
db
et
host
dans la
base
mysql
durant les deux étapes. Les champs de cette table sont les suivants :
Table name
|
utilisateur
|
base
|
hôte
|
Scope fields
|
Host
|
Host
|
Host
|
|
User
|
Db
|
Db
|
|
Password
|
User
|
|
Privilege fields
|
Select_priv
|
Select_priv
|
Select_priv
|
|
Insert_priv
|
Insert_priv
|
Insert_priv
|
|
Update_priv
|
Update_priv
|
Update_priv
|
|
Delete_priv
|
Delete_priv
|
Delete_priv
|
|
Index_priv
|
Index_priv
|
Index_priv
|
|
Alter_priv
|
Alter_priv
|
Alter_priv
|
|
Create_priv
|
Create_priv
|
Create_priv
|
|
Drop_priv
|
Drop_priv
|
Drop_priv
|
|
Grant_priv
|
Grant_priv
|
Grant_priv
|
|
References_priv
|
References_priv
|
References_priv
|
|
Reload_priv
|
|
|
|
Shutdown_priv
|
|
|
|
Process_priv
|
|
|
|
File_priv
|
|
|
|
Show_db_priv
|
|
|
|
Super_priv
|
|
|
|
Create_tmp_table_priv
|
Create_tmp_table_priv
|
Create_tmp_table_priv
|
|
Lock_tables_priv
|
Lock_tables_priv
|
Lock_tables_priv
|
|
Execute_priv
|
|
|
|
Repl_slave_priv
|
|
|
|
Repl_client_priv
|
|
|
|
ssl_type
|
|
|
|
ssl_cypher
|
|
|
|
x509_issuer
|
|
|
|
x509_cubject
|
|
|
|
max_questions
|
|
|
|
max_updates
|
|
|
|
max_connections
|
|
|
Lors de la seconde étape du contrôle d'accès (vérification de la requête), le
serveur peut, suivant la requête, consulter aussi les tables
tables_priv
et
columns_priv
. Les champs de ces tables
sont :
Nom de la table
|
tables_priv
|
columns_priv
|
Champ
|
Host
|
Host
|
|
Db
|
Db
|
|
User
|
User
|
|
Table_name
|
Table_name
|
|
|
Column_name
|
Droit
|
Table_priv
|
Column_priv
|
|
Column_priv
|
|
Autre champ
|
Timestamp
|
Timestamp
|
|
Grantor
|
|
Chaque table de droit contient des champs d'identification et des champs
de droits.
-
Les champs d'identification déterminent quels utilisateurs correspondent à cette
ligne dans la table. Par exemple, une ligne dans la table
user
avec les
valeurs dans les colonnes
Host
et
User
de
'thomas.loc.gov'
et
'bob'
servira à identifier les connexions qui sont faites par l'utilisateur
bob
depuis l'hôte
thomas.loc.gov
. De même, une ligne dans la table
db
avec les valeurs des colonnes
Host
,
User
et
Db
de
'thomas.loc.gov'
,
'bob'
et
'reports'
sera utilisée lorsque
l'utilisateur
bob
se connecte depuis l'hôte
thomas.loc.gov
pour
accéder à la base
reports
. Les tables
tables_priv
et
columns_priv
contiennent en plus des champs indiquant les tables et combinaisons tables et colonnes
auxquelles les lignes s'appliquent.
-
Les champs de droits indiquent si le droit est donné, c'est à dire si l'opération
indiquée peut être exécuté. Le serveur combine les informations dans différentes
tables pour former une description complète de l'utilisateur. Les règles
utilisées sont décrites dans Contrôle d'accès, étape 2 : vérification des requêtes .
Les champs d'identification sont des chaînes, déclarées comme suit.
La valeur par défaut de chacun des champs est la chaîne vide.
Nom de la colonne
|
Type
|
Host
|
CHAR(60)
|
User
|
CHAR(16)
|
Password
|
CHAR(16)
|
Db
|
CHAR(64)
|
Table_name
|
CHAR(60)
|
Column_name
|
CHAR(60)
|
Avant MySQL 3.23, la colonne
Db
valait
CHAR(32)
dans certaines tables,
et
CHAR(60)
dans d'autres.
Pour vérifier les accès, la comparaison sur les valeurs de la colonne
Host
sont sensibles à la casse.
User
,
Password
,
Db
et
Table_name
sont insensibles.
Les valeurs de
Column_name
sont insensibles depuis MySQL 3.22.12.
Dans les tables
user
,
db
et
host
,
tous les champs de droits sont déclarés avec le type
ENUM('N','Y')
:
il peuvent prendre tous les valeurs de
'N'
(non) ou
'Y'
(oui, YES),
et la valeur par défaut est
'N'
.
Dans les tables
tables_priv
et
columns_priv
, les champs de
droits sont déclarés comme des champs de type
SET
:
Nom de la table
|
Nom du champs
|
Valeurs possibles
|
tables_priv
|
Table_priv
|
'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
|
tables_priv
|
Column_priv
|
'Select', 'Insert', 'Update', 'References'
|
columns_priv
|
Column_priv
|
'Select', 'Insert', 'Update', 'References'
|
En bref, le serveur utilise les tables de droits comme ceci :
-
La table
user
détermine si le serveur accepte ou rejette la connexion.
Pour les connexions acceptées, tous les privilèges donnés dans la table
user
indiquent des privilèges globaux. Ces droits d'appliquent
à
toutes
les bases du serveur.
-
Les champs d'identification de la table
db
déterminent quels utilisateurs
peuvent accéder à quelles bases, depuis quel hôte.
Les champs de droits indiquent alors les opérations permises.
Les droits s'appliquent alors à
toutes
les bases sur le serveur.
-
La table
host
est utilisée comme extension de la table
db
lorsque vous
voulez qu'une ligne de la table
db
s'applique à plusieurs hôtes. Par exemple,
si vous voulez qu'un utilisateur soit capable d'utiliser une base depuis plusieurs
hôtes dans votre réseau, laissez la colonne
Host
vide dans la table
db
,
Ce mécanisme est décrit en détails dans 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 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 Quand est-ce que les droits prennent effets .
Lorsque vous modifiez le contenu des tables de droits, c'est une bonne idée
que de s'assurer que vous avez bien configuré les droits qui vous intéressent.
Un moyen de vérifier les droits pour un compte est d'utiliser la commande
SHOW GRANTS
.
Par exemple, pour déterminer les droits qui sont donnés à un compte avec les valeurs
Host
et
User
de
pc84.example.com
et
bob
,
utilisez cette commande :
mysql> SHOW GRANTS FOR 'bob'@'pc84.example.com';
|
Un outil de diagnostique pratique est le script
mysqlaccess
, que Yves Carlier
a fourni à la distribution MySQL. Appelez
mysqlaccess
avec l'option
the
--help
pour comprendre comment il fonctionne.
Notez que
mysqlaccess
ne vérifie les accès que pour les tables
user
,
db
et
host
. Il n'utilise pas les tables de droit de niveau
table ou colonne.
Pour plus d'aide au diagnostique pour les problèmes de droits, voyez la
section Causes possibles de l'erreur
Access denied
. Pour des conseils généraux sur la sécurité, voyez
la section Problèmes généraux de sécurité .
|