4.2 Règles de sécurité et droits d'accès au serveur MySQL
4 Administration du serveur
Manuel de Référence MySQL 4.1 : Version Française
. Instructions générales de sécurité . Comment protéger MySQL contre les pirates . Options de démarrage qui concernent la sécurité . Problèmes de sécurité avec LOAD DATA LOCAL . 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 . Causes des erreurs Access denied
|
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
.
Syntaxe de
GRANT
et
REVOKE
. (Vous pouvez aussi vous reporter à la section
Comment le système de droits fonctionne 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
:
- 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.
- 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.
- 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.
|