Управление доступом к базам MySQL
Система управления базами данных MySQL очень часто применяется для хранения важной информации на веб-сайтах. Если это обычный сайт или форум – в базе могут храниться сообщения пользователей, данные для динамических страниц, данные о посещениях, если это какой-либо интерактивный сервис, то кроме данных про доступ (конфиденциальных), там хранится и другая информация о пользователе и его действиях. Все это приводит к тому, что общая безопасность сайта, вернее всей веб-системы, зависит от того, насколько защищен именно сервер базы данных.
На обычных виртуальных хостингах каждый клиент получает свой логин и пароль, и ему доступна только одна база, в которой он может создавать произвольное количество таблиц. Один и тот же физический сервер БД используют разные клиенты, каждый из которых имеет доступ только до одной определенной базы данных. Ситуация, когда у пользователя одна база, за владение которой сражаются и «движок» форума (которому требуется создать сотню и больше таблиц), и скрипты списков рассылки, новостей, поисковый скрипт, а если еще установлена система управления контентом (CMS) или электронный магазин – тогда в этой базе возникает такое огромное количество различных таблиц, порой с очень странными и ничего не обозначающими названиями (хорошо, если два скрипта не используют таблицы с одинаковыми названиями, но разной структурой). В таких случаях очень желательно иметь возможность создать несколько отдельных баз данных, и выделить их для разных приложений (к примеру, одна база для форума, другая для электронного магазина).
Кроме сложностей с управлением несколькими сотнями таблиц в одной базе, вы столкнетесь с необходимостью ограничивать доступ разных пользователей к таблицам, базам и даже отдельным столбцам конкретной таблицы. Спешим вас успокоить – разработчики СУБД MySQL уже позаботились о подобной ситуации – в MySQL есть очень гибкий и мощный механизм управления и разграничения доступа пользователей к базам и таблицам.
Работает этот механизм, естественно, через служебные таблицы. В списке баз данных есть одна служебная база под названием «mysql», в которой хранятся в нескольких таблицах все служебные данные, необходимые для работы сервера. Пока нас интересует только управление правами доступа, за которые отвечают следующие таблицы:
- columns_priv – доступ на уровне столбцов таблицы;
- db – доступ к отдельным базам данных;
- host – доступ к базам с конкретных хостов/IP;
- tables_priv – доступ к отдельным таблицам базы данных;
- user – глобальные настройки доступа для конкретных пользователей.
Давайте детально рассмотрим таблицу user и специфику работы с ней, работа же с остальными таблицами аналогична и не будет сложнее.
Права, определяемые в таблице user, являются глобальными, это значит, что они применяются ко всем базам данных, к которым имеет доступ конкретных пользователь. Также в этой таблице хранятся сами имена пользователей и их пароли. Причем имена пользователей хранятся в виде открытого текста, а пароли зашифрованы функцией PASSWORD(). Сервер MySQL применяет свой метод шифрования вместо системного (если такая функция предоставляется ОС, к примеру, Linux/UNIX).
Поскольку MySQL предназначена для работы через сеть, то к серверу могут подключаться клиенты с различных хостов. Поэтому в таблице привилегий есть столбец host, в котором можно задать конкретный компьютер, IP или диапазон адресов, с которых определенный пользователь (или все, любые пользователи) могут подключаться, или же им полностью запрещен доступ. К примеру, если ваш тестовый сервер находится в локальной сети, то можно выборочно разрешить доступ к нему с отдельных компьютеров, а для всех остальных полностью заблокировать доступ.
Если для одного и того же пользователя надо разрешить доступ с различных компьютеров, то в таблице привилегий надо создать две (три или больше – сколько понадобится) записей, определяя в каждой отдельный параметр доступа. К примеру, для доступа пользователя root с компьютеров localhost и 192.168.1.138 надо в таблицу user внести две одинаковые записи, которые различаются только полем host. Хотя можно, конечно, и не делать их одинаковыми – тогда тот же пользователь, но в зависимости от места, откуда он подключился, будет иметь разные привилегии.
Значение столбца host можно задавать в различных форматах. Это может быть как имя хоста – localhost, так и IP-адрес – 192.168.1.138. При необходимости, можно применять символы подстановки. Они аналогичны тем же. Что применяются в синтаксисе SQL-запросов. Символ «_» означает любой символ, а «%» — любое количество символов. К примеру, для разрешения доступа с любого компьютера, содержащего в имени hostinfo.ru надо прописать %.hostinfo.ru в столбце host. Таким же способом можно задавать и диапазоны IP-адресов. Для задания маски сети доступен также вариант написания через слеш – 192.168.1/255. Для глобального задания доступа можно в столбце host прописать только символ «%» или оставить его пустым, что равнозначно.
Следующие поля – user и password, определяют имя и пароль пользователя. Эти поля уже, в отличие от host, различают регистр введенных символов, поэтому пользователь Root и root – это два разных пользователя. Знаки подстановки в этом поле уже не работают – имя пользователя %» означает не «любой пользователь», а именно «пользователь с именем %». Для задания анонимного пользователя надо просто оставить поле пустым, иначе любой символ будет считаться именем пользователя. Так же и в поле password – пароль хранится в зашифрованном виде, знаки подстановки недействительны, а пустое поле означает, что пользователь вовсе не должен указывать пароль, а не то, что пароль может быть произвольным. Напомним, что просто пароль (пусть и зашифрованный) нельзя помещать в поле password, предварительно его надо шифровать функцией PASSWORD(«пароль_открытым_текстом»). Например:
Следующим полем является поле базы данных – db. В других таблицах оно также присутствует, поэтому во всех таблицах правила написания имен баз данных должны быть одинаковыми. Разрешается использовать символы подстановки «%» и «_», пустое значение соответствует «все базы». Поле чувствительно к регистру!
Далее идет целый набор столбцов, разрешающие те или иные действия для пользователя. К примеру, Select_priv, Insert_priv, Update_priv, Delete_priv, Index_priv и Alter_priv стоит установить в «Y» (разрешено) для обычного пользователя, так как такие запросы чаще всего встречаются в обычных приложениях. Остальные возможности для большей безопасности надо отключить для всех пользователей (особенно, если есть учетная запись анонимного пользователя). Поэтому в следующих столбцах — Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv и References_priv надо выставить значение «N»(запрещено), а при необходимости разрешить действия только администратору и максимально ограничить возможности подключения такого пользователя – указать конкретный IP-адрес или имя компьютера, выбрать длинный и сложный для подбора пароль.
Аналогична таблице user и таблица db, в которой можно задавать отдельные привилегии для конкретных баз данных. Таким образом, можно разрешить пользователям создавать новые таблицы только в своих базах данных и запретить даже простой просмотр чужих баз. Синтаксис всех полей полностью аналогичный таблице user.
При подключении пользователя сервер MySQL сначала обрабатывает таблицу user (записанные там правила доступа глобальные), а потом, если прав недостаточно или нельзя определить права доступа к конкретной базе – тогда уже поиск продолжается в таблице db. Если же и во второй таблице нет соответствующих привилегий, сервер пробует найти их в таблицах tables_priv и columns_priv. И только когда на основании информации со всех доступных таблиц сервер определяет, что клиенту не разрешено запрошенное действие, он отвергает клиентский запрос.
Таблица host также аналогична описанным выше, только вместо имен и паролей пользователей для идентификации привилегий служит имя хоста или IP-адрес. На первый взгляд, есть существенное дублирование информации. Ведь таблицы db и host почти равнозначны и содержат одинаковые данные. На самом деле это немного не так. Таблица host недоступна для изменения через операторы SQL GRANT и REVOKE, ее можно только править непосредственно. Когда сервер принимает решение о допуске клиента к базам, он сначала ищет упоминание имени хоста или IP в таблице host. Если там присутствует соответствующая запись, то тогда права из таблиц host и db обьединяються и клиент получает некоторые привилегии. Если же в таблице host нет указаний на счет хоста или IP, то сервер даже не рассматривает дальше таблицу db, так как если клиенту не разрешено подключение с хоста, то тогда бессмысленно искать права на доступ к отдельным базам.
How to SHOW USERS in MySQL and User Information Using Linux
A MySQL database server is often the go-to choice for developers and anyone willing to test a structured query language. MySQL has many features that make it reliable, secure, and efficient.
However, there are some ways to increase MySQL server security even more. One of them is to create users with limited permissions on the database.
In this tutorial, we’ll provide more context for why you should create separate MySQL user accounts and go over how to use the MySQL SHOW USERS command on your Linux server.
Why Create Users in MySQL Server?
Whenever users or database administrators install MySQL, the first user that will be created is the root user – the MySQL administrator. The root user will have permissions to do everything on the MySQL database.
While having all the permissions can seem beneficial, doing so comes with its own security flaws, and sharing the root user between several people is dangerous. Hackers often try to log in as the root user and steal the hosted information or even destroy the whole MySQL server alongside its data.
Thus, system administrators create users with specific permissions on some databases. In other words, if credentials for one account get compromised, the impact will be minimal and manageable.
How to SHOW USERS in MySQL Database on Linux
Unlike the SHOW DATABASES or SHOW TABLES commands that display all databases or tables right away, the SHOW USERS command does not exist in MySQL. Even though there is no such command, users can use a MySQL query and get a full list of users in a given MySQL database server.
Follow the steps below for more information.
1. Log in as the MySQL Root User
Start by logging in to the VPS via SSH as the root user. Once that’s done, enter the MySQL command line with this command:
Then, enter your MySQL root password.
Important! Keep in mind that system and MySQL root passwords are separate and can differ.
Once you are in the MySQL console as the root user, you will be able to run queries to display other MySQL users.
2. Use the MySQL SHOW USERS Query
Use the following query to show MySQL users created in the database server:
As a result, you will see the list of all the users that have been created in MySQL.
Take note that there might be duplicate users. This is because MySQL filters access to a server according to the IP address it comes from.
You can also add a host column to see even more information using the following command:
With this, you will be able to see the MySQL users and which host or IP address they have permission to access. In our case, all of the users are from a local database:
3. See More MySQL User Info (Optional)
If you need more information about MySQL users, the search command can be expanded with the help of MySQL queries.
For example, the following command will print out all possible information from the user table:
However, such output might look too messy to figure out. Thus, we recommend narrowing the search by using more specific queries.
Here are some of the more popular use-cases:
Preview Table Columns
The following query will display a preview of user table columns. It is especially helpful if users want to check information about a specific table.
Display Only Unique Usernames
To skip repeating usernames, the following query can be used:
Password Expiration and Account Locking Status
In order to check the password expiration status and account locking state, use this query:
Show Current and Current Logged Users
The current user can be displayed with the following query:
If you need more information, you can modify the query to display currently logged-in users with their states. This command is beneficial for finding idle users that use up too many resources.
Conclusion
The administration of a database server can be challenging work. Thus, database administrators must be careful when creating and administering user permissions.
The MySQL SHOW USERS command allows administrators to view MySQL users alongside other important information.
To recap, we’ve covered the basics of how to show MySQL users tied to a database and learned how to:
- List all users created in a given MySQL database
- Preview MySQL database table columns
- Display only the unique usernames in a table
- Check password expiration and account locking status
- Show current and currently logged-in users in a MySQL database
We hope that you found this tutorial helpful. If you have any additional questions or insights, let us know in the comments section below.
Learn More About Database Management Systems
MySQL Show Users FAQ
How Can I See All MySQL Users and Passwords?
Make the following SQL query:
mysql> select user, password, host from mysql. user
This query brings up a list of users, their usernames, passwords, and database host.
How Do I Show Users in MySQL MariaDB?
Log into your MariaDB/MySQL server with the mysql client as a root user. Type the following query:
$ mysql -u root –p
Or
$ mysql –u root –h localhost –p mysql
Where Are Users Stored in MySQL?
MySQL stores users in the user table within the database.
Ignas takes great satisfaction in helping people tackle even the most complex technical issues. His current goal is to write easy-to-follow articles so that these issues will not happen at all. During his free time, Ignas likes to play video games and fix up things around his house.
Как найти и сменить пароль пользователя MySQL?
Как узнать пароль MySQL или не ищем приключений на свою голову
Дата публикации:
2016-05-03
От автора:
вы куда полезли через ограду, гражданин! На заборе написали пароль, чтоб не забыть. Так может вы с этой стороны написали? Да нет – это не мой написан. Ну, удачных поисков, а всем остальным я расскажу, как узнать пароль MySQL, не перелезая через чужие заборы.
Нет ничего проще!
Если у вас есть элементарные знания и навыки обращения с СУБД MySQL, и (главное) учетная запись администратора, то узнать пароли всех пользователей можно в два счета. Для этого можно использовать как программные оболочки, так и команды SQL.
Что представляет собой сервер СУБД? Это обычная база данных, содержащая в себе всю нужную для работы MySQL информацию. Здесь хранятся все настройки сервера, баз, сведения о плагинах, дате и времени, пользовательские учетные записи, их привилегиях и паролях. В контексте данной статьи нас интересует значения последних.
Чтобы узнать пароль MySQL, нужно зайти на сервер под своей учеткой администратора. Затем открыть системную базу данных с именем «mysql» и сделать выборку значений из таблицы user. Для наглядности все интересующие сведения (значения паролей) мы получим с помощью php MyAdmin.
Откроем системную БД, и посмотрим на содержимое нужной нам таблицы «сблизи»: в одном из ее столбцов прописаны все пароли. Как видите, ничего сложного и для этого нам понадобилось всего несколько минут. Но что это такое? Кто «стибрил» из таблицы понятные значения паролей и заменил их какой-то «абракадаброй»!
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
Получить курс сейчас!
Спокойствие, и только спокойствие! Никто ничего «не стибрил», просто в таблице указываются уже хешированные пароли. А что у вас глаза такие удивленные? Сейчас все разложим «по полочкам».
Как происходит шифрование в MySQL
Дело в том, что данная СУБД использует собственный алгоритм шифрования паролей. Точнее, не шифрования, а хеширования. Из-за этого пока никто не придумал способа, как расшифровать пароли в MySQL.
Существуют различные алгоритмы хеширования, но если при этом будет использоваться криптографическая толь, то шансов получить значение пароля сводится почти к 0. Криптографическая соль – это дополнительная строка, которая присоединяется к первоначальному значению. В результате на выходе (после хеширования) получается почти «невзламываемый» пароль.
Для установки пароля СУБД использует функцию PASSWORD(). Она не возвращает значения, которое было послано ей на обработку. Поэтому использовать данную функцию для получения «читаемого» пароля не получится. Единственное, что можно сделать – это получить хешированную строку по первоначальному значению. Синтаксис запроса:
Это же значение можно найти в системной таблице user (служебная база данных mysql), куда заносятся все учетные записи пользователей СУБД и хешированные значения паролей.
Путем перебора (если знать хотя бы примерную структуру значения) можно попытаться вспомнить забытый пароль. Но восстановить таким образом полностью неизвестное значение практически невозможно. Помните, что все описанные выше операции производятся под учетной записью администратора (root).
Использование обратимого шифрования
Узнать пароль MySQL, заданный системой по умолчанию для учетных записей сервера не удастся. Но это можно реализовать на уровне баз данных или даже таблиц. Многие движки и CMS, работающие на основе MySQL, имеют собственную (встроенную) систему аутентификации.
Например, если открыть таблицу БД WordPress, где движок сохраняет все данные о пользователях, то в столбце user_pass вы увидите такую же «абракадабру», как и в системной базе MySQL. Это говорит о том, что данная CMS также использует один из алгоритмов необратимого шифрования паролей (md5).
Но можно реализовать схему аутентификации на основе обратимых методов шифрования. Этим и займемся. Не будем сегодня огорчать себя «черным» цветом, и все запросы SQL выполним не через командную строку, а в phpMyAdmin. Для экспериментов я воспользуюсь тестовой БД «db1», в которой хранится одна таблица со «зверюшками» (animal). Добавим новую таблицу с именами хозяев зверей и паролем для входа в их «клетки»
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
Получить курс сейчас!
Теперь перед тем, как узнать пароль MySQL, давайте заполним созданную таблицу данными. Для этого мы снова используем запросы SQL, как поступают настоящие разработчики. Код запроса:
Меняя значения в скобках после оператора VALUES, добавьте в таблицу еще несколько строк. Теперь сделаем из нее выборку данных:
Вообще-то непорядок получается! Значение паролей всех пользователей видны «как на ладони». Сейчас мы их слегка «хешанем» с помощью встроенной функции AES_ENCRYPT. Она принимает 2 параметра: столбец для хеширования и значение «соли»:
Теперь давайте еще раз сделаем выборку из таблицы и посмотрим на ее результаты:
Как видите, одни «блобы» получились вместо паролей. Это говорит о том, что значения надежно хешированы, и без «соли» взломать их практически невозможно. Но мы с вами знаем, в чем «соль». Сейчас я вам покажу, как узнать пароли к базе данных MySQL, точнее вернуть их в более «читаемом» виде. Для этого используется другая функция — AES_DECRYPT(). Код запроса с ее «участием»:
Результаты этой выборки:
Как видите, чтобы узнать пароль MySQL, нужно правильно понимать, в чем «соль» проблемы. А если лазить по чужим заборам, то можно запросто получить заряд соли (из ружья) в то место, на которое не стоит лишний раз искать приключений. Лучше это время потратить на изучение MySQL.
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
Управление доступом к базам MySQL
Система управления базами данных MySQL очень часто применяется для хранения важной информации на веб-сайтах. Если это обычный сайт или форум — в базе могут храниться сообщения пользователей, данные для динамических страниц, данные о посещениях, если это какой-либо интерактивный сервис, то кроме данных про доступ (конфиденциальных), там хранится и другая информация о пользователе и его действиях. Все это приводит к тому, что общая безопасность сайта, вернее всей веб-системы, зависит от того, насколько защищен именно сервер базы данных.
На обычных виртуальных хостингах каждый клиент получает свой логин и пароль, и ему доступна только одна база, в которой он может создавать произвольное количество таблиц. Один и тот же физический сервер БД используют разные клиенты, каждый из которых имеет доступ только до одной определенной базы данных. Ситуация, когда у пользователя одна база, за владение которой сражаются и «движок» форума (которому требуется создать сотню и больше таблиц), и скрипты списков рассылки, новостей, поисковый скрипт, а если еще установлена система управления контентом (CMS) или электронный магазин — тогда в этой базе возникает такое огромное количество различных таблиц, порой с очень странными и ничего не обозначающими названиями (хорошо, если два скрипта не используют таблицы с одинаковыми названиями, но разной структурой). В таких случаях очень желательно иметь возможность создать несколько отдельных баз данных, и выделить их для разных приложений (к примеру, одна база для форума, другая для электронного магазина).
Кроме сложностей с управлением несколькими сотнями таблиц в одной базе, вы столкнетесь с необходимостью ограничивать доступ разных пользователей к таблицам, базам и даже отдельным столбцам конкретной таблицы. Спешим вас успокоить — разработчики СУБД MySQL уже позаботились о подобной ситуации — в MySQL есть очень гибкий и мощный механизм управления и разграничения доступа пользователей к базам и таблицам.
Работает этот механизм, естественно, через служебные таблицы. В списке баз данных есть одна служебная база под названием «mysql», в которой хранятся в нескольких таблицах все служебные данные, необходимые для работы сервера. Пока нас интересует только управление правами доступа, за которые отвечают следующие таблицы:
 |
Давайте детально рассмотрим таблицу user и специфику работы с ней, работа же с остальными таблицами аналогична и не будет сложнее.
Права, определяемые в таблице user, являются глобальными, это значит, что они применяются ко всем базам данных, к которым имеет доступ конкретных пользователь. Также в этой таблице хранятся сами имена пользователей и их пароли. Причем имена пользователей хранятся в виде открытого текста, а пароли зашифрованы функцией PASSWORD(). Сервер MySQL применяет свой метод шифрования вместо системного (если такая функция предоставляется ОС, к примеру, Linux/UNIX).
Поскольку MySQL предназначена для работы через сеть, то к серверу могут подключаться клиенты с различных хостов. Поэтому в таблице привилегий есть столбец host, в котором можно задать конкретный компьютер, IP или диапазон адресов, с которых определенный пользователь (или все, любые пользователи) могут подключаться, или же им полностью запрещен доступ. К примеру, если ваш тестовый сервер находится в локальной сети, то можно выборочно разрешить доступ к нему с отдельных компьютеров, а для всех остальных полностью заблокировать доступ.
Если для одного и того же пользователя надо разрешить доступ с различных компьютеров, то в таблице привилегий надо создать две (три или больше — сколько понадобится) записей, определяя в каждой отдельный параметр доступа. К примеру, для доступа пользователя root с компьютеров localhost и 192.168.1.138 надо в таблицу user внести две одинаковые записи, которые различаются только полем host. Хотя можно, конечно, и не делать их одинаковыми — тогда тот же пользователь, но в зависимости от места, откуда он подключился, будет иметь разные привилегии.
Значение столбца host можно задавать в различных форматах. Это может быть как имя хоста — localhost, так и IP-адрес — 192.168.1.138. При необходимости, можно применять символы подстановки. Они аналогичны тем же. Что применяются в синтаксисе SQL-запросов. Символ «_» означает любой символ, а «%» — любое количество символов. К примеру, для разрешения доступа с любого компьютера, содержащего в имени hostinfo.ru надо прописать %.hostinfo.ru в столбце host. Таким же способом можно задавать и диапазоны IP-адресов. Для задания маски сети доступен также вариант написания через слеш — 192.168.1/255. Для глобального задания доступа можно в столбце host прописать только символ «%» или оставить его пустым, что равнозначно.
 |
Следующие поля — user и password, определяют имя и пароль пользователя. Эти поля уже, в отличие от host, различают регистр введенных символов, поэтому пользователь Root и root — это два разных пользователя. Знаки подстановки в этом поле уже не работают — имя пользователя %» означает не «любой пользователь», а именно «пользователь с именем %». Для задания анонимного пользователя надо просто оставить поле пустым, иначе любой символ будет считаться именем пользователя. Так же и в поле password — пароль хранится в зашифрованном виде, знаки подстановки недействительны, а пустое поле означает, что пользователь вовсе не должен указывать пароль, а не то, что пароль может быть произвольным. Напомним, что просто пароль (пусть и зашифрованный) нельзя помещать в поле password, предварительно его надо шифровать функцией PASSWORD(«пароль_открытым_текстом»). Например:
INSERT INTO user SET host=»192.168.1.138″, user=»raiden», password=PASSWORD(«my_password»);
Следующим полем является поле базы данных — db. В других таблицах оно также присутствует, поэтому во всех таблицах правила написания имен баз данных должны быть одинаковыми. Разрешается использовать символы подстановки «%» и «_», пустое значение соответствует «все базы». Поле чувствительно к регистру!
Далее идет целый набор столбцов, разрешающие те или иные действия для пользователя. К примеру, Select_priv, Insert_priv, Update_priv, Delete_priv, Index_priv и Alter_priv стоит установить в «Y» (разрешено) для обычного пользователя, так как такие запросы чаще всего встречаются в обычных приложениях. Остальные возможности для большей безопасности надо отключить для всех пользователей (особенно, если есть учетная запись анонимного пользователя). Поэтому в следующих столбцах — Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv и References_priv надо выставить значение «N»(запрещено), а при необходимости разрешить действия только администратору и максимально ограничить возможности подключения такого пользователя — указать конкретный IP-адрес или имя компьютера, выбрать длинный и сложный для подбора пароль.
Аналогична таблице user и таблица db, в которой можно задавать отдельные привилегии для конкретных баз данных. Таким образом, можно разрешить пользователям создавать новые таблицы только в своих базах данных и запретить даже простой просмотр чужих баз. Синтаксис всех полей полностью аналогичный таблице user.
При подключении пользователя сервер MySQL сначала обрабатывает таблицу user (записанные там правила доступа глобальные), а потом, если прав недостаточно или нельзя определить права доступа к конкретной базе — тогда уже поиск продолжается в таблице db. Если же и во второй таблице нет соответствующих привилегий, сервер пробует найти их в таблицах tables_priv и columns_priv. И только когда на основании информации со всех доступных таблиц сервер определяет, что клиенту не разрешено запрошенное действие, он отвергает клиентский запрос.
Таблица host также аналогична описанным выше, только вместо имен и паролей пользователей для идентификации привилегий служит имя хоста или IP-адрес. На первый взгляд, есть существенное дублирование информации. Ведь таблицы db и host почти равнозначны и содержат одинаковые данные. На самом деле это немного не так. Таблица host недоступна для изменения через операторы SQL GRANT и REVOKE, ее можно только править непосредственно. Когда сервер принимает решение о допуске клиента к базам, он сначала ищет упоминание имени хоста или IP в таблице host. Если там присутствует соответствующая запись, то тогда права из таблиц host и db обьединяються и клиент получает некоторые привилегии. Если же в таблице host нет указаний на счет хоста или IP, то сервер даже не рассматривает дальше таблицу db, так как если клиенту не разрешено подключение с хоста, то тогда бессмысленно искать права на доступ к отдельным базам.