The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Базы данных, SQL" / Оглавление документа

4.2 Общие проблемы защиты и система привилегий доступа MySQL

MySQL имеет продвинутую, но ненормативную систему защиты и привилегий. Этот подробно раздел описывает, как она работает.

4.2.1 Общие принципы защиты

Любой, использующий MySQL на компьютере, связанном с Internet, должен прочитать этот раздел, чтобы избежать наиболее общих ошибок защиты.

Очень важно уделить внимание проблемам безопасности всего сервера (а не только MySQL) и защите от всех типов атак.

MySQL использует защиту, основанную на списках управления доступом (Access Control Lists ACL) для всех подключений, запросов и других операций, которые пользователь может пытаться выполнять. Имеется также поддержка для соединений, зашифрованных SSL между клиентами и сервером MySQL. Многие из понятий, обсуждаемых здесь, не специфические для MySQL: те же самые общие идеи применимы вообще почти ко всем прикладным программам.

При запуске MySQL следуйте этим руководящим принципам:

4.2.2 Как защитить MySQL от крекеров

Когда Вы соединяетесь с сервером MySQL, Вы обычно должны использовать пароль. Он не передается открытым текстом, однако, алгоритм шифрования не очень силен, и с некоторым усилием умный нападаюший может расколоть пароль, если может перехватить трафик. Если подключение между пользователем и сервером проходит недоверенную сеть, Вы должны использовать SSH-туннель, чтобы шифровать связь. Увы, хакеры сделали шифрование совершенно мирной связи обычным делом. А думали ли мы все, что через три года будем совершенно спокойно воспринимать шифрование данных не в военных системах, а дома?

Вся другая информация будет перемещена как текст, который может читаться любым, кто способен наблюдать подключение. Если Вы обеспокоены относительно этого, Вы можете использовать сжатый протокол (в MySQL версии 3.22 и выше), чтобы делать такое чтение намного тяжелее. Чтобы сделать связь более безопасной, Вы должны использовать ssh. Вы можете скачать исходные тексты клиентской части ssh с http://www.openssh.org, коммерческая версия клиента ssh доступна на http://www.ssh.com. Теперь Вы можете получить шифрованное TCP/IP подключение к серверу MySQL.

Чтобы сделать систему MySQL безопасной, Вы должны внимательно рассмотреть следующие предложения:

4.2.3 Параметры запуска для mysqld, связанные с защитой

Следующие параметры mysqld воздействуют на защиту:

--safe-show-database
С этой опцией SHOW DATABASES возвращает только те базы данных, для которых пользователь имеет некоторую привилегию.
--safe-user-create
Если включено, пользователь не может создавать новых пользователей командой GRANT, если он не имеет права INSERT на таблице mysql.user. Если Вы хотите давать пользователю доступ к созданию новых пользователей с теми привилегиями, которые он имеет право предоставить, Вы должны дать ему следующую привилегию:
GRANT INSERT(user) on mysql.user to 'user''hostname';
Это гарантирует, что пользователь не может изменять любые столбцы привилегий непосредственно, а должен использовать команду GRANT, чтобы дать привилегии другим пользователям.
--skip-grant-tables
Эта опция заставляет сервер не использовать систему привилегий вообще. Это дает каждому полный доступ ко всем базам данных! Вы можете сообщить, чтобы сервер начал использовать таблицы привилегий снова, выполняя команду mysqladmin flush-privileges или mysqladmin reload.
--skip-name-resolve
Не преобразовывать имена. Все значения столбца Host в таблицах предоставления привилегий должны быть IP-адресами или localhost.
--skip-networking
Не слушать TCP/IP подключения вообще. Все взаимодействие с mysqld должно быть выполнено через сокеты Unix. Эта опция очень рекомендуется на системах, где позволяются только локальные запросы. Эта опция не подходит для систем, которые используют MIT-PTHREADS потому, что пакет MIT-PTHREADS не поддерживает Unix-сокеты.
--skip-show-database
Инструкция SHOW DATABASES не будет возвращать ничего.

4.2.4 Что делает система привилегий

Первичная функция системы привилегий MySQL состоит в том, что она должна опознать пользователя, соединяющегося с данного компьютера, и сопоставить этого пользователя с привилегиями на базе данных типа select, insert, update и delete.

Дополнительные функциональные возможности включают способность иметь анонимного пользователя и предоставлять привилегии для MySQL-функций, типа LOAD DATA INFILE, и административных операций.

4.2.5 Как работает система привилегий

Система привилегий MySQL гарантирует, что все пользователи могут делать точно те дела, которые им будут позволены. Когда Вы соединяетесь с сервером MySQL, Вы будете идентифицированы не только по логину, который ввели, но и по адресу хоста, с которого зашли в сеть.

MySQL позволяет Вам отличить пользователей с различных компьютеров, которые, случается, имеют то же самое имя, Вы можете предоставлять один набор привилегий для подключений с одной системы, и совсем другой для того же имени, но с другой машины.

Управление доступом MySQL включает две стадии:

Сервер использует таблицы user, db и host в базе данных mysql на обеих стадиях управления доступа. Поля в этих таблицах показаны ниже:
Имя таблицыuser dbhost
Поля контекстаHost HostHost
UserDb Db
PasswordUser
Поля привилегийSelect_priv Select_privSelect_priv
Insert_privInsert_priv Insert_priv
Update_privUpdate_priv Update_priv
Delete_privDelete_priv Delete_priv
Index_privIndex_priv Index_priv
Alter_privAlter_priv Alter_priv
Create_privCreate_priv Create_priv
Drop_privDrop_priv Drop_priv
Grant_privGrant_priv Grant_priv
References_priv
Reload_priv
Shutdown_priv
Process_priv
File_priv

Для второй стадии управления доступом (проверка запроса) сервер может, если запрос включает таблицы, дополнительно консультироваться с таблицами tables_priv и columns_priv. Поля этих таблиц:
Имя таблицыtables_priv columns_priv
Поля контекстаHost Host
DbDb
UserUser
Table_nameTable_name
Column_name
Поля привилегийTable_priv Column_priv
Column_priv
Прочие поляTimestamp Timestamp
Grantor

Каждая таблица содержит поля области (контекста) и поля привилегий.

Поля контекста определяют область (контекст) каждой записи в таблицах, то есть тот контекст, в котором применяется данная запись. Например, запись в таблице user со значениями Host и User 'thomas.loc.gov' и 'bob' соответственно использовалась бы для подтверждения подключений, сделанных на сервер пользователем bob с компьютера thomas.loc.gov. Точно так же запись таблицы db с полями Host, User и Db, выставленными соответственно в thomas.loc.gov, bob и reports, использовалась бы, когда bob соединяется с компьютера thomas.loc.gov, чтобы обратиться к базе данных отчетов (reports). Таблицы tables_priv и columns_priv хранят поля области (контекста), указывающие таблицы или комбинации таблицы/столбца, к которым применяется каждая запись.

Для целей проверки доступа значения Host нечувствительны к регистру. Зато User, Password, Db и значения Table_name еще как чувствительны! Column_name нечувствительны в MySQL версии 3.22.12 или позже.

Поля привилегий указывают привилегии, предоставленные записью таблицы, то есть какие операции могут выполняться. Сервер объединяет информацию из различных таблиц предоставления привилегий, чтобы сформировать полное описание прав данного пользователя. Правила, используемые, чтобы это сделать, подробно описаны в разделе "4.2.9 Контроль доступа, стадия 2: Проверка запросов".

Поля контекста представляют собой строки, объявленные как показано ниже. Значение по умолчанию для каждой: пустая строка:

Имя поляТип
HostCHAR(60)
UserCHAR(16)
Password CHAR(16)
DbCHAR(64) (CHAR(60) для таблиц tables_priv и columns_priv)
Table_nameCHAR(60)
Column_nameCHAR(60)

В таблицах user, db и host все поля привилегий объявлены как ENUM('N','Y'): каждое может иметь значение 'N' или 'Y', значение по умолчанию 'N'.

В таблицах tables_priv и columns_priv поля привилегий объявлены как поля SET:

Имя таблицыИмя поля Возможные элементы набора
tables_privTable_priv 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
tables_privColumn_priv 'Select', 'Insert', 'Update', 'References'
columns_priv Column_priv 'Select', 'Insert', 'Update', 'References'

Сервер использует таблицы предоставления подобно этому алгоритму:

Обратите внимание, что административные привилегии (reload, shutdown и т.д.) определены только в таблице user. Это потому, что административные операции выполняются непосредственно на сервере и не специфические для базы данных, так что нет никакой причины внести в список такие привилегии в других таблицах. Фактически, только таблица user должна использоваться, чтобы определить, можете ли Вы выполнять административную операцию или нет.

Привилегия file также определена только в таблице user. Это не административная привилегия, но Ваша способность читать или писать файлы на компьютере сервера также независима от базы данных, к которой Вы обращаетесь.

Сервер mysqld читает содержание таблиц только один раз, при своем запуске. Изменения для таблиц предоставления привилегий вступают в силу как сказано в разделе "4.3.3 Когда изменения привилегий вступают в силу".

Когда Вы изменяете содержание таблиц предоставления, стоит удостовериться, что Ваши изменения установили привилегии так, как Вы хотите. Для справки в диагностировании проблем обратитесь в раздел "4.2.10 Причины ошибки Access denied. Проблемы с защитой подробно рассмотрены в разделе "4.2.2 Как защитить MySQL от хакеров".

Полезный диагностический инструмент: скрипт mysqlaccess, который Yves Carlier предоставил для дистрибутива MySQL. Вызовите mysqlaccess с опцией --help, чтобы выяснить, как это работает. Обратите внимание, что mysqlaccess проверяет доступ, используя только таблицы user, db и host. Это не проверяет привилегии уровня столбца или таблицы.

4.2.6 Привилегии, предоставляемые MySQL

Информация относительно привилегий пользователя сохранена в таблицах user, db, host, tables_priv и columns_priv в базе данных mysql. Сервер MySQL читает содержание этих таблиц при запуске и при обстоятельствах, перечисленных в разделе "4.3.3 Когда изменения привилегий вступают в силу".

Имена, используемые в этом руководстве, чтобы обратиться к привилегиям, обеспеченным MySQL, показываются ниже, наряду с именем столбца таблицы, связанным с каждой привилегией в таблицах предоставления привилегий и контекста, в котором данная привилегия применяется:

ПривилегияСтолбец Контекст (поле) действия
selectSelect_priv таблицы
insertInsert_priv таблицы
updateUpdate_priv таблицы
deleteDelete_priv таблицы
indexIndex_priv таблицы
alterAlter_priv таблицы
createCreate_privбазы данных, таблицы или индексы
dropDrop_privбазы данных или таблицы
grantGrant_privбазы данных или таблицы
referencesReferences_priv базы данных или таблицы
reloadReload_priv серверное администрирование
shutdownShutdown_priv серверное администрирование
processProcess_priv серверное администрирование
fileFile_privдоступ к файлам на сервере

Привилегии select, insert, update и delete позволяют Вам выполнять операции на строках в существующих таблицах в базе данных.

Инструкции SELECT требуют привилегии select только, если они фактически восстанавливают строки из таблицы. Вы можете выполнять некоторые инструкции SELECT даже без разрешения обратиться к любой из баз данных на сервере. Например, Вы могли бы использовать клиента mysql как простой калькулятор:

mysql> SELECT 1+1;
mysql> SELECT PI()*2;

Привилегия index позволяет создавать или удалять индексы.

Привилегия alter позволяет использовать ALTER TABLE.

Привилегии create и drop позволяют создавать новые базы данных и таблицы или удалять существующие.

Обратите внимание, что, если Вы предоставляете привилегию drop для базы данных mysql пользователю, он сможет удалить всю базу данных, в которой сохранены привилегии доступа MySQL!

Привилегия grant позволяет Вам давать другим пользователям те привилегии, которыми Вы непосредственно обладаете.

Привилегия file дает Вам разрешение читать и писать файлы на сервере, используя инструкции LOAD DATA INFILE и SELECT ... INTO OUTFILE. Любой пользователь, кому эта привилегия предоставляется, может читать или писать любой файл, который доступен на чтение или запись серверу MySQL.

Оставшиеся привилегии используются для административных операций, которые выполняются, используя программу mysqladmin. Таблица ниже показывает, какие команды mysqladmin соответствуют привилегиям:

ПривилегияКоманды, разрешенные держателям данной привилегии
reloadreload, refresh, flush-privileges, flush-hosts, flush-logs и flush-tables
shutdownshutdown
processprocesslist, kill

Команда reload сообщает, что сервер должен заново прочитать таблицы предоставления привилегий. Команда refresh сбрасывает на диск все таблицы, закрывает и заново открывает журналы. Привилегия flush-privileges является синонимом для reload. Другие команды flush-* выполняют функции, подобные refresh, но в более ограниченном контексте, и могут быть предпочтительны в некоторых ситуациях. Например, если Вы хотите только сбросить на диск журналы, команда flush-logs представляет собой лучший выбор, чем refresh.

Команда shutdown выключает сервер.

Команда processlist отображает информацию относительно процессов, выполняющихся внутри сервера. Команда kill уничтожает потоки сервера. Вы всегда можете отображать или уничтожать Ваши собственные процессы, но Вы нуждаетесь в привилегии process, чтобы отображать или уничтожать процессы, инициализированные другими пользователями. Подробности в разделе "4.5.4 Синтаксис KILL".

Некоторые предосторожности при предоставлении привилегий:

Имеются некоторые вещи, которые Вы не можете делать с системой привилегий MySQL:

4.2.7 Соединение с сервером MySQL

Клиент MySQL требует, чтобы Вы определили параметры подключения, когда Вы хотите обратиться к серверу MySQL: компьютер, с которым надо связаться, Ваше имя пользователя и пароль. Например, клиент mysql может быть запущен примерно так (факультативные параметры заключены в `[' и `]'):

shell> mysql [-h host_name] [-u user_name] [-pyour_pass]

Альтернативные формы параметров -h, -u и -p: --host=host_name, --user=user_name и --password=your_pass. Обратите внимание, что не должно быть никаких пробелов вообще между -p или --password= и паролем.

ОБРАТИТЕ ВНИМАНИЕ: Определение пароля в командной строке далеко не безопасно! Любой пользователь в Вашей системе может выяснить Ваш пароль командой, наподобие ps auxww. Подробности в разделе "4.1.2 Файл опций my.cnf".

mysql использует значения по умолчанию для параметров подключения, которые отсутствуют в командной строке:

Таким образом, для Unix-пользователя joe эквивалентно:

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

Другая MySQL-клиентура ведет себя аналогично.

На Unix-системах Вы можете определять различные значения по умолчанию, которые нужно использовать, когда Вы делаете подключение, так, чтобы не надо было вводить их в командную строку, каждый раз, когда Вы вызываете программу. Это может быть выполнено двумя разными способами:

4.2.8 Контроль доступа, стадия 1: Проверка соединения

Когда Вы пытаетесь соединиться с сервером MySQL, он принимает или отклоняет подключение, исходя из Вашей идентификации и того, можете ли Вы подтвердить ее паролем. Если нет, сервер отвергает доступ полностью. Иначе сервер принимает подключение, затем вводит Стадию 2 и ждет запросы.

Идентификация основана на двух частях информации:

Проверка выполняется, используя три поля области (контекста) таблицы user (Host, User и Password). Сервер принимает подключение только, если запись таблицы user соответствует Вашему hostname и имени пользователя, и Вы вводите правильный пароль.

Значения в полях области (контекста) таблицы user могут быть определены следующим образом:

Непустые значения Password представляют зашифрованные пароли. MySQL не сохраняет пароли в форме открытого текста. Пароли шифруются функцией PASSWORD(). Зашифрованный пароль затем используется, когда клиент/сервер проверяет, является ли пароль правильным (это будет выполнено без передачи зашифрованного пароля по сети). Обращаю внимание, что с точки зрения MySQL зашифрованный пароль представляет собой РЕАЛЬНЫЙ пароль, так что Вы не должны давать доступ к нему кому попало! В частности, не давайте нормальный доступ для чтения пользователям к таблицам в базе данных mysql!

Примеры ниже показывают, как различные комбинации значений Host и User в записях таблицы user обращаются к входящим подключениям:

Hostзначение User значениеПодключения, согласованные записью
'thomas.loc.gov''fred' fred, связавшийся с машины thomas.loc.gov
'thomas.loc.gov'''Любой пользователь, связавшийся с машины thomas.loc.gov
'%''fred' fred, связавшийся с любой машины
'%'''Любой пользователь, связавшийся с любой машины
'%.loc.gov''fred' fred, связавшийся с любой машины в домене loc.gov
'x.y.%''fred'fred , связавшийся с x.y.net, x.y.com, x.y.edu и т.д.
'144.155.166.177''fred' fred, связавшийся с машины с IP-адресом 144.155.166.177
'144.155.166.%''fred' fred, связавшийся с любой машины в сети 144.155.166 коасса C
'144.155.166.0/255.255.255.0''fred' Аналогично предыдущему примеру

Поскольку Вы можете использовать символы подстановки в IP-адресах в поле Host (например, '144.155.166.%', чтобы соответствовать каждому компьютеру в подсети), есть возможность, что кто-то может попробовать эксплуатировать это свойство, именуя свой компьютер 144.155.166.somewhere.com. Чтобы мешать таким попыткам, MySQL отвергает соответствие имен хостов, которые начинаются с цифр и точки. Таким образом, если Вы имеете компьютер с именем наподобие 3.6.foo.com, его имя никогда не будет соответствовать столбцу Host таблиц. Только IP-адрес может соответствовать символам подстановки в IP-адресе.

Входящее подключение может быть согласовано более, чем с одной записью в таблице user. Например, подключение пользователя fred с машины thomas.loc.gov согласовано несколькими записями, показанными выше. Как сервер выбирает, которую запись использовать в данной ситуации? Он решает этот вопрос, сортируя таблицу user после ее чтения при запуске. Затем записи просматриваются в отсортированном порядке. Используется первое совпадение.

Сортировка таблицы user работает следующим образом. Предположим, что таблица user выглядит следующим образом:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

Когда сервер читает таблицу, он располагает записи с наиболее специфическими значениями Host вначале ('%' в столбце Host означает любой компьютер, а, стало быть, наименее специфический). Записи с одинаковыми значениями Host упорядочиваются с наиболее специфическими значениями User (пустое значение User означает любого пользователя, и наименее специфическое). Возникающая в результате сортировки таблица user выглядит следующим образом:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

Когда предпринято подключение, сервер просматривает отсортированные записи и использует первое найденное соответствие. Для подключения пользователя jeffrey с машины localhost записи со значением 'localhost' в столбце Host окажутся первыми. Из них подходит запись с пустым именем пользователя. Запись '%'/'jeffrey' тоже подходит, но она не первая.

Имеется другой пример. Предположите, что таблица user выглядит следующим образом:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

Отсортированная таблица будет выглядеть так:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

Подключение пользователя jeffrey с машины thomas.loc.gov согласовано первой записью в то время, как подключение jeffrey с машины whitehouse.gov соответствует второй записи.

Общее неправильное мнение состоит в том, что первыми будут использованы записи, в которых имя пользователя указано явно. Это не так! Только что было показано, что запись, использованная первой, имени пользователя в явном виде не имела вовсе.

Если Вы имеете проблемы при соединении с сервером, распечатайте таблицу user и отсортируйте ее вручную, чтобы видеть, где первое соответствие будет сделано.

4.2.9 Контроль доступа, стадия 2: Проверка запросов

Как только Вы устанавливаете подключение, сервер вводит Стадию 2. Для каждого запроса, который входит на подключении, сервер проверяет, имеете ли Вы достаточные привилегии, чтобы выполнить его, основываясь на типе операции. Эти привилегии могут исходить из любой из таблиц: user, db, host, tables_priv или columns_priv. Таблицы предоставления привилегий управляются с помощью команд GRANT и REVOKE. Подробности в разделе "4.3.1 Синтаксис GRANT и REVOKE".

Таблица user предоставляет привилегии, которые назначены Вам на глобальном основании, и это применяется независимо от того, какова текущая база данных. Например, если таблица user предоставляет Вам привилегию delete, Вы можете удалять строки из любой базы данных на сервере! Другими словами, привилегии таблицы user являются глобальными. Мудро предоставить привилегии в таблице user только суперпользователям типа администраторов базы данных или сервера в целом. Для других пользователей Вы должны оставить привилегии в таблице user в значении 'N' и давать их только при использовании таблиц db и host.

Таблицы db и host предоставляют специфические для базы данных привилегии. Значения в полях области могут быть определены так:

Таблицы db и host читаются и сортируются при запуске сервера по тем же правилам, что и таблица user.

Таблицы tables_priv и columns_priv предоставляют специфические для таблицы и столбца привилегии. Значения в полях области (контекста) могут быть определены так:

Таблицы tables_priv и columns_priv сортируются по полям Host, Db и User. Это подобно сортировке таблицы db, хотя сортировка более простая потому, что только поле Host может содержать групповые символы.

Процесс проверки запроса описан ниже.

Для административных запросов (shutdown, reload и т.д.), сервер проверяет только запись таблицы user потому, что это единственная таблица, которая определяет административные привилегии. Доступ предоставляется, если запись позволяет запрошенную операцию. Например, если Вы хотите выполнить mysqladmin shutdown, но Ваша запись в таблице user не предоставляет Вам привилегию shutdown, доступ будет отклонен без всякой проверки таблиц db или host.

Для связанных с базой данных запросов (insert, update и т.д.), сервер сначала проверит глобальные привилегии (суперпользователя) по записям в таблице user. Если запись позволяет запрошенную операцию, доступ предоставляется. Если глобальные привилегии в таблице user недостаточны, сервер определяет специфические для базы данных привилегии пользователя, проверяя таблицы db и host:

  1. Сервер смотрит в таблице db соответствия полей Host, Db и User. Поля Host и User должны соответствовать hostname соединяющегося клиентского компьютера и MySQL-имени пользователя. Поле Db должно соответствовать базе данных, к которой пользователь хочет обращаться. Если не имеется никакой записи для Host и User, доступ будет отклонен.
  2. Если имеется соответствие записи в таблице db и ее поле Host не пустое, то данная запись определяет специфические для базы данных привилегии пользователя.
  3. Если в соответствующей записи таблицы db поле Host является пустым, это выражает, что таблица host перечисляет, какие именно компьютеры имеют доступ к базе данных. В этом случае дальнейшая поисковая работа ведется в таблице host, чтобы найти соответствие полей Host и Db. Если соответствий в таблице host нет, доступ будет отклонен. Если имеется соответствие, специфические для базы данных привилегии пользователя будут вычислены как пересечение (но не объединение!) привилегий в таблицах db и host, то есть, привилегий, которые являются 'Y', в обеих записях.

После определения специфических для базы данных привилегий, предоставленных записями таблиц db и host, сервер добавляет их к глобальным привилегиям, предоставленным таблицей user. Если результат позволяет запрошенную операцию, доступ предоставляется. Иначе сервер проверяет пользовательские привилегии таблицы и столбца в таблицах tables_priv и columns_priv соответственно, добавляя их к привилегиям пользователя.

Выражаясь в терминах двоичной логики, предшествующее описание того, как привилегии пользователя будут вычислены, может быть получено так:

global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges

Не очень ясно, почему, если первоначально найдены глобальные привилегии пользователя в таблице user, недостаточные для запрошенной операции, сервер добавляет их к привилегиям для базы данных, таблицы и специфического столбца. Причина в том, что запрос может требовать больше, чем один тип привилегии. Например, если Вы выполняете инструкцию INSERT ... SELECT, Вы нуждаетесь в привилегиях insert и select. Ваши привилегии могут быть такими, что запись таблицы user предоставляет одну из них, а запись таблицы db разрешает другую. В этом случае Вы имеете необходимые привилегии, чтобы выполнить запрос, но сервер должен просмотреть все таблицы, чтобы разобраться в ситуации: привилегии, предоставленные записями в обеих таблицах, должны быть объединены вместе.

Таблица host может использоваться, чтобы поддерживать список безопасных машин и серверов.

В TcX таблица host хранит список всех машин в локальной сети. Им предоставляют все привилегии.

Вы можете также использовать таблицу host, чтобы указать компьютеры, которые не безопасны. Предположите, что Вы имеете машину public.your.domain, которая размещена в общем домене, который Вы не рассматриваете как безопасный. Вы можете позволять доступ всем компьютерам в Вашей сети за исключением этой системы, используя записи в таблице host:

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (все привилегии установлены в 'N')
| %.your.domain      | %  | ... (все привилегии установлены в 'Y')
+--------------------+----+-

Естественно, Вы должны всегда проверять Ваши записи в таблицах предоставления привилегий (например, используя mysqlaccess), чтобы удостовериться, что Ваши привилегии доступа фактически установлены так, как Вы ожидаете.

4.2.10 Причины ошибки Access denied

Если Вы сталкиваетесь с ошибкой Access denied, когда пробуете соединиться с сервером MySQL, посмотрите список ниже. Там приведены наиболее часто встречающиеся проблемы.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру