Spec-Zone .ru
спецификации, руководства, описания, API
|
После того, как Вы устанавливаете соединение, сервер вводит Этап 2 из управления доступом. Для каждого запроса,
который Вы выпускаете через то соединение, сервер определяет, какую работу Вы хотите выполнить, затем проверяет,
есть ли у Вас достаточные полномочия сделать так. Это - то, где столбцы полномочия в таблицах предоставления
играют роль. Эти полномочия могут прибыть из любого из user
, db
,
tables_priv
, columns_priv
, или procs_priv
таблицы. (Можно счесть полезным обратиться к Разделу 6.2.2,
"Полномочие Систем Грант Тэбльз", который перечисляет столбцы, существующие в каждой из таблиц
предоставления.)
user
таблица предоставляет полномочия, которые присваиваются Вам на глобальной
основе и которые применяют независимо от того, какова база данных значения по умолчанию. Например, если user
таблица предоставляет Вам DELETE
полномочие, можно удалить строки из любой таблицы в любой базе данных
на узле сервера! Мудро предоставить полномочия в user
таблица только людям, которые
нуждаются в них, такие как администраторы базы данных. Для других пользователей следует оставить все полномочия
внутри user
настольный приемник к 'N'
и полномочия
предоставления на более определенных уровнях только. Можно предоставить полномочия для определенных баз данных,
таблиц, столбцов, или подпрограмм.
db
таблица предоставляет специфичные для базы данных полномочия. Значения в столбцах
контекста этой таблицы могут принять следующие формы:
Пробел User
оцените соответствует анонимному
пользователю. Непустое значение соответствует буквально; в именах пользователей нет никаких
подстановочных знаков.
Подстановочные символы"%
"и"_
"может использоваться в Host
и Db
столбцы. У них есть то же самое значение что касается операций
сопоставления с образцом, выполняемых с LIKE
оператор. Если Вы хотите использовать любой символ буквально,
предоставляя полномочия, следует выйти из него с наклонной чертой влево. Например, чтобы включать символ
подчеркивания ("_
")
как часть имени базы данных, определите это как"\_
"в GRANT
оператор.
A '%'
или пробел Host
значение означает "любой узел."
A '%'
или пробел Db
значение означает "любую базу данных."
Сервер читает db
таблица в память и виды это в то же самое время, когда это читает
user
таблица. Сервер сортирует db
таблица, основанная
на Host
, Db
, и User
столбцы контекста. Как с user
таблица, сортировка помещает самые специфичные
значения первые и наименее специфичные последние значения, и когда сервер ищет соответствие записей, это
использует первое соответствие, которое это находит.
tables_priv
, columns_priv
, и procs_priv
табличное предоставление специфичные для таблицы, специфичные для столбца, и стандартно-специфичные полномочия.
Значения в столбцах контекста этих таблиц могут принять следующие формы:
Подстановочные символы"%
"и"_
"может использоваться в Host
столбец. У них есть то же самое значение что касается операций сопоставления с образцом, выполняемых с
LIKE
оператор.
A '%'
или пробел Host
значение означает "любой узел."
Db
, Table_name
, Column_name
, и Routine_name
столбцы не могут
содержать подстановочные знаки или быть пробелом.
Сервер сортирует tables_priv
, columns_priv
, и procs_priv
таблицы, основанные на Host
, Db
, и User
столбцы. Это подобно db
табличная сортировка, но более простой, потому что только Host
столбец может содержать подстановочные знаки.
Сервер использует сортированные таблицы, чтобы проверить каждый запрос, который он получает. Для запросов,
которые требуют административных привилегий такой как SHUTDOWN
или RELOAD
, сервер проверяет только user
строка
таблицы, потому что это - единственная таблица, которая определяет административные привилегии. Сервер
предоставляет доступ, если строка разрешает требуемую работу и лишает доступа иначе. Например, если Вы хотите
выполнить mysqladmin
завершение работы, но Ваш user
строка таблицы не
предоставляет SHUTDOWN
полномочие Вам, сервер лишает доступа, даже не проверяя db
таблица. (Это содержит
нет Shutdown_priv
столбец, таким образом нет никакой потребности сделать так.)
Для связанных с базой данных запросов (INSERT
,
UPDATE
,
и так далее), сервер первые проверки глобальные полномочия пользователя, заглядывая user
строка таблицы. Если строка разрешает требуемую работу, доступ
предоставляется. Если глобальные полномочия в user
таблица недостаточна, сервер
определяет специфичные для базы данных полномочия пользователя, проверяя db
таблица:
Сервер заглядывает db
таблица для соответствия на Host
,
Db
, и User
столбцы. Host
и User
столбцы являются соответствующими к имени хоста соединяющегося пользователя
и имени пользователя MySQL. Db
столбец является соответствующим к базе данных, к
которой пользователь хочет получить доступ. Если нет никакой строки для Host
и
User
, доступ лишается.
После определения специфичных для базы данных полномочий, предоставленных db
записи
таблицы, сервер добавляет их к глобальным полномочиям, предоставленным user
таблица. Если результат разрешает требуемую работу, доступ предоставляется. Иначе, сервер последовательно
регистрирует таблицу пользователя, и столбец дает полномочия tables_priv
и columns_priv
таблицы, добавляют те к полномочиям пользователя, и разрешают или
лишают доступа, основанного на результате. Для операций сохраненной подпрограммы сервер использует procs_priv
таблица, а не tables_priv
и columns_priv
.
Выраженный в логических членах, предыдущее описание того, как полномочия пользователя вычисляются, может быть получено в итоге как это:
global privilegesOR (database privileges AND host privileges)OR table privilegesOR column privilegesOR routine privileges
Это, возможно, не очевидно почему, если глобальная переменная user
полномочия
строки, как первоначально находят, недостаточны для требуемой работы, сервер добавляет те полномочия к базе
данных, таблице, и полномочиям столбца позже. Причина состоит в том, что запрос мог бы потребовать больше чем
одного типа полномочия. Например, если Вы выполняетесь INSERT INTO ... SELECT
оператор, Вы нуждаетесь в обоих INSERT
и SELECT
полномочия. Ваши полномочия могли бы быть так, что user
строка таблицы предоставляет одно полномочие и db
строка таблицы предоставляет другой. В этом случае у Вас есть необходимые
полномочия выполнить запрос, но сервер не может сказать это от любой таблицы отдельно; полномочия,
предоставленные записями в обеих таблицах, должны быть объединены.