Question Utiliser% for host lors de la création d'un utilisateur MySQL


Ma base de données MySQL a besoin de deux utilisateurs: appuser et support.
L'un des développeurs d'applications insiste pour que je crée quatre comptes pour ces utilisateurs:

appuser@'%'
appuser@'localhost'
support@'%'
support@'localhost'

Pour la vie de moi, je ne peux pas comprendre pourquoi il pense que nous avons besoin de cela. Ne pas utiliser le joker comme hôte prendrait en charge le "localhost"?

Des idées?

(En utilisant MySQL 5.5 ici)


59
2018-05-30 20:34


origine


Réponses:


Le signe de pourcentage signifie que toutes les adresses IP sont superflues, donc localhost est inutile ... Le deuxième enregistrement avec localhost est inutile.

MODIFIER 

En fait, "localhost" est spécial dans mysql, cela signifie une connexion sur un socket unix (ou des canaux nommés sur windows, je crois) par opposition à un socket TCP / IP. utiliser% comme hôte n'inclut pas 'localhost'


81
2018-05-30 20:35



Comme l'a souligné @nos dans les commentaires de la réponse actuellement acceptée à cette question, la réponse acceptée est incorrecte.

Oui, il y a une différence entre % et localhost pour l'hôte du compte utilisateur lors de la connexion via une connexion socket au lieu d'une connexion TCP / IP standard.

Une valeur d'hôte de % n'inclus pas localhost pour les sockets et doit donc être spécifié si vous souhaitez vous connecter en utilisant cette méthode.


27
2018-06-13 16:27



Si vous voulez vous connecter à user@'%' à partir de l'utilisation de localhost mysql -h192.168.0.1 -uuser -p.


5
2018-05-13 08:19



Aller à fournir une réponse légèrement différente de celles fournies jusqu'à présent.

Si vous avez une ligne pour un utilisateur anonyme de localhost dans votre table d'utilisateurs ''@'localhost' alors ce sera traité comme plus spécifique que votre utilisateur avec l'hôte générique 'user'@'%'. C'est pourquoi il est nécessaire de fournir également 'user'@'localhost'.

Vous pouvez voir cela expliqué plus en détail au bas de cette page.


4
2018-01-19 04:50



Le symbole de pourcentage signifie: tout hôte, y compris les connexions distantes et locales.

Le localhost n'autorise que les connexions locales.

(pour commencer, si vous n'avez pas besoin de connexions distantes à votre base de données, vous pouvez vous débarrasser immédiatement de l'utilisateur appuser @ '%')

Donc, oui, ils se chevauchent, mais ...

... il y a une raison pour configurer les deux types de comptes, ceci est expliqué dans les documents mysql: http://dev.mysql.com/doc/refman/5.7/en/adding-users.html.

Si vous avez un utilisateur anonyme sur votre localhost, que vous pouvez repérer avec:

select Host from mysql.user where User='' and Host='localhost';

et si vous créez simplement l’utilisateur appuser @ '%' (et pas l’appuser @ 'localhost'), alors lorsque l’utilisateur appuser mysql se connecte depuis l'hôte local, le compte utilisateur anonyme est utilisé (il a la priorité sur votre utilisateur appuser @ '%').

Et le correctif pour cela est (comme on peut le deviner) pour créer le nom d'utilisateur "localhost" (qui est plus spécifique que l'utilisateur anonyme de l'hôte local et sera utilisé si votre utilisateur se connecte depuis l'hôte local).


3
2018-02-04 12:05



Essayons juste de tester.

Connectez-vous en tant que superutilisateur, puis:

SHOW VARIABLES LIKE "%version%"; 
+-------------------------+------------------------------+ 
| Variable_name           | Value                        | 
+-------------------------+------------------------------+ 
| version                 | 10.0.23-MariaDB-0+deb8u1-log | 

et alors

USE mysql;

Installer

Créer un utilisateur foo avec mot de passe bar pour tester:

CREATE USER foo@'%' IDENTIFIED BY 'bar'; FLUSH PRIVILEGES;

Relier

Pour vous connecter au socket de domaine Unix (c'est-à-dire le canal d'E / S nommé par l'entrée du système de fichiers) /var/run/mysqld/mysqld.sockou un tel), exécutez ceci sur la ligne de commande (utilisez le --protocol option pour faire doublement sûr)

mysql -pbar -ufoo
mysql -pbar -ufoo --protocol=SOCKET

On s'attend à ce que les correspondances ci-dessus "utilisateur provient de localhost" mais certainement pas "l'utilisateur provient de 127.0.0.1".

Pour vous connecter au serveur à partir de "127.0.0.1", exécutez ceci sur la ligne de commande

mysql -pbar -ufoo --bind-address=127.0.0.1 --protocol=TCP

Si vous laissez de côté --protocol=TCP, la mysql commande essaiera toujours d'utiliser le socket de domaine Unix. Vous pouvez également dire:

mysql -pbar -ufoo --bind-address=127.0.0.1 --host=127.0.0.1

Les deux tentatives de connexion sur une seule ligne:

export MYSQL_PWD=bar; \
mysql -ufoo --protocol=SOCKET --execute="SELECT 1"; \
mysql -ufoo --bind-address=127.0.0.1 --host=127.0.0.1 --execute="SELECT 1"

(le mot de passe est défini dans l'environnement pour qu'il soit transmis au mysql processus)

Vérification en cas de doute

Pour vérifier si la connexion passe par un socket TCP / IP ou un socket de domaine Unix

  1. obtenir le PID du processus client mysql en examinant la sortie de ps faux
  2. courir lsof -n -p<yourpid>.

Vous verrez quelque chose comme:

mysql [PID] quux 3u IPv4 [code] 0t0 TCP 127.0.0.1:[port]->127.0.0.1:mysql (ESTABLISHED)

ou

mysql [PID] quux 3u unix [code] 0t0 [code] socket

Alors:

Cas 0: Host = '10.10.10.10 '(test nul)

update user set host='10.10.10.10' where user='foo'; flush privileges;
  • Connecter en utilisant socket: FAILURE
  • Connecter à partir de 127.0.0.1: FAILURE

Cas 1: Host = '%'

update user set host='%' where user='foo'; flush privileges;
  • Connecter en utilisant le socket: OK
  • Connecter à partir de 127.0.0.1: OK

Cas 2: Host = 'localhost'

update user set host='localhost' where user='foo';flush privileges;

Le comportement varie et cela dépend apparemment de skip-name-resolve. Si défini, provoque des lignes avec localhost à ignorer selon le journal. Ce qui suit peut être vu dans le journal des erreurs: "'utilisateur' entrée 'root @ localhost' ignoré en mode --skip-name-resolve.". Cela signifie pas de connexion via le socket de domaine Unix. Mais ce n'est empiriquement pas le cas. localhost signifie maintenant UNIQUEMENT le socket de domaine Unix, et ne correspond plus à 127.0.0.1.

skip-name-resolve est éteint:

  • Connecter en utilisant le socket: OK
  • Connecter à partir de 127.0.0.1: OK

skip-name-resolve est sur:

  • Connecter en utilisant le socket: OK
  • Connecter à partir de 127.0.0.1: FAILURE

Cas 3: Hôte = '127.0.0.1'

update user set host='127.0.0.1' where user='foo';flush privileges;
  • Connecter en utilisant socket: FAILURE
  • Connecter à partir de 127.0.0.1: OK

Cas 4: Host = ''

update user set host='' where user='foo';flush privileges;
  • Connecter en utilisant le socket: OK
  • Connecter à partir de 127.0.0.1: OK

(Selon MySQL 5.7: 6.2.4 Contrôle d'accès, étape 1: vérification de la connexion, La chaîne vide '' signifie aussi "tout hôte" mais trie après "%". )

Cas 5: Host = '192.168.0.1' (test supplémentaire)

('192.168.0.1' est l'une des adresses IP de ma machine, changez de manière appropriée dans votre cas)

update user set host='192.168.0.1' where user='foo';flush privileges;
  • Connecter en utilisant socket: FAILURE
  • Connecter à partir de 127.0.0.1: FAILURE

mais

  • Connecter en utilisant mysql -pbar -ufoo -h192.168.0.1: D'ACCORD (!)

Le dernier parce que c'est en fait la connexion TCP provenant de 192.168.0.1, comme révélé par lsof:

TCP 192.168.0.1:37059->192.168.0.1:mysql (ESTABLISHED)

Edge Case A: Host = '0.0.0.0'

update user set host='0.0.0.0' where user='foo';flush privileges;
  • Connecter en utilisant socket: FAILURE
  • Connecter à partir de 127.0.0.1: FAILURE

Bord B: Host = '255.255.255.255'

update user set host='255.255.255.255' where user='foo';flush privileges;
  • Connecter en utilisant socket: FAILURE
  • Connecter à partir de 127.0.0.1: FAILURE

Edge Case C: Host = '127.0.0.2'

(127.0.0.2 est l’adresse de bouclage parfaitement valide équivalente à 127.0.0.1 telle que définie dans RFC6890)

update user set host='127.0.0.2' where user='foo';flush privileges;
  • Connecter en utilisant socket: FAILURE
  • Connecter à partir de 127.0.0.1: FAILURE

Intéressant:

  • mysql -pbar -ufoo -h127.0.0.2 se connecte de 127.0.0.1 et est échec
  • mysql -pbar -ufoo -h127.0.0.2 --bind-address=127.0.0.2 est OK

Nettoyer

delete from user where user='foo';flush privileges;

Addenda

Pour voir ce qui est réellement dans le mysql.user table, qui est l'une des tables d'autorisation, utilise:

SELECT SUBSTR(password,1,6) as password, user, host,
Super_priv AS su,
Grant_priv as gr,
CONCAT(Select_priv, Lock_tables_priv) AS selock,
CONCAT(Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv) AS modif,
CONCAT(References_priv, Index_priv, Alter_priv) AS ria,
CONCAT(Create_tmp_table_priv, Create_view_priv, Show_view_priv) AS views,
CONCAT(Create_routine_priv, Alter_routine_priv, Execute_priv, Event_priv, Trigger_priv) AS funcs,
CONCAT(Repl_slave_priv, Repl_client_priv) AS replic,
CONCAT(Shutdown_priv, Process_priv, File_priv, Show_db_priv, Reload_priv, Create_user_priv) AS admin
FROM user ORDER BY user, host;

cela donne:

+----------+----------+-----------+----+----+--------+-------+-----+-------+-------+--------+--------+
    | password | user     | host      | su | gr | selock | modif | ria | views | funcs | replic | admin  |
    +----------+----------+-----------+----+----+--------+-------+-----+-------+-------+--------+--------+
    | *E8D46   | foo      |           | N  | N  | NN     | NNNNN | NNN | NNN   | NNNNN | NN     | NNNNNN |

De même pour la table mysql.db:

SELECT host,db,user, 
       Grant_priv as gr,
       CONCAT(Select_priv, Lock_tables_priv) AS selock, 
       CONCAT(Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv) AS modif, 
       CONCAT(References_priv, Index_priv, Alter_priv) AS ria, 
       CONCAT(Create_tmp_table_priv, Create_view_priv, Show_view_priv) AS views, 
       CONCAT(Create_routine_priv, Alter_routine_priv, Execute_priv) AS funcs 
       FROM db ORDER BY user, db, host;

3
2018-03-06 18:49