Spec-Zone.ru › MySQL 9.2

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

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

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

  • Привилегии базы данных применяются к базе данных и всем объектам в ней. Эти привилегии могут быть предоставлены для конкретных баз данных или глобально, чтобы они применялись ко всем базам данных.

  • Привилегии для объектов базы данных, таких как таблицы, индексы, представления и хранимые процедуры, могут быть предоставлены для конкретных объектов внутри базы данных, для всех объектов данного типа внутри базы данных (например, для всех таблиц в базе данных) или глобально для всех объектов данного типа во всех базах данных.

Привилегии также различаются по своему характеру — статические (встроенные в сервер) или динамические (определяемые во время выполнения). Статический или динамический характер привилегии влияет на возможность их предоставления учетным записям и ролям. Дополнительную информацию о различиях между статическими и динамическими привилегиями см. в разделе Статические и динамические привилегии.

Информация о привилегиях учетной записи хранится в таблицах разрешений в базе данных системы mysql. Подробное описание структуры и содержимого этих таблиц см. в разделе разделе 8.2.3, «Таблицы разрешений». При запуске сервер MySQL считывает содержимое таблиц разрешений в оперативную память и перезагружает их в указанных в разделе 8.2.13, «Когда вступают в силу изменения привилегий» условиях. Решения о контроле доступа сервер основывает на копиях таблиц разрешений в оперативной памяти.

Важно

Некоторые версии MySQL вносят изменения в таблицы разрешений, добавляя новые привилегии или функции. Чтобы использовать новые возможности, обновляйте таблицы разрешений до текущей структуры при каждом обновлении MySQL. См. главу 3, «Обновление MySQL».

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

  • Обзор доступных привилегий

  • Описание статических привилегий

  • Описание динамических привилегий

  • Рекомендации по предоставлению привилегий

  • Статические и динамические привилегии

  • Миграция учетных записей с SUPER на динамические привилегии

Обзор доступных привилегий

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

Таблица 8.2 Разрешенные статические привилегии для GRANT и REVOKE

Таблица 8.2 Разрешенные статические привилегии для GRANT и REVOKE
Привилегия Столбец таблицы разрешений Контекст
ALL [PRIVILEGES] Синоним для “все привилегии” Администрирование сервера
ALTER Alter_priv Таблицы
ALTER ROUTINE Alter_routine_priv Хранимые процедуры
CREATE Create_priv Базы данных, таблицы или индексы
CREATE ROLE Create_role_priv Администрирование сервера
CREATE ROUTINE Create_routine_priv Хранимые процедуры
CREATE TABLESPACE Create_tablespace_priv Администрирование сервера
CREATE TEMPORARY TABLES Create_tmp_table_priv Таблицы
CREATE USER Create_user_priv Администрирование сервера
CREATE VIEW Create_view_priv Представления
DELETE Delete_priv Таблицы
DROP Drop_priv Базы данных, таблицы или представления
DROP ROLE Drop_role_priv Администрирование сервера
EVENT Event_priv Базы данных
EXECUTE Execute_priv Хранимые процедуры
FILE File_priv Доступ к файлам на хосте сервера
GRANT OPTION Grant_priv Базы данных, таблицы или хранимые процедуры
INDEX Index_priv Таблицы
INSERT Insert_priv Таблицы или столбцы
LOCK TABLES Lock_tables_priv Базы данных
PROCESS Process_priv Администрирование сервера
PROXY См. таблицу proxies_priv Администрирование сервера
REFERENCES References_priv Базы данных или таблицы
RELOAD Reload_priv Администрирование сервера
REPLICATION CLIENT Repl_client_priv Администрирование сервера
REPLICATION SLAVE Repl_slave_priv Администрирование сервера
SELECT Select_priv Таблицы или столбцы
SHOW DATABASES Show_db_priv Администрирование сервера
SHOW VIEW Show_view_priv Представления
SHUTDOWN Shutdown_priv Администрирование сервера
SUPER Super_priv Администрирование сервера
TRIGGER Trigger_priv Таблицы
UPDATE Update_priv Таблицы или столбцы
USAGE Синоним для “без привилегий” Администрирование сервера

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

Таблица 8.3 Разрешенные динамические привилегии для GRANT и REVOKE

Таблица 8.3 Разрешенные динамические привилегии для GRANT и REVOKE
Привилегия Контекст
ALLOW_NONEXISTENT_DEFINER Защита от объектов-сирот
APPLICATION_PASSWORD_ADMIN Управление паролями приложений
AUDIT_ABORT_EXEMPT Разрешить запросы, заблокированные фильтром журнала аудита
AUDIT_ADMIN Управление журналом аудита
AUTHENTICATION_POLICY_ADMIN Управление аутентификацией
BACKUP_ADMIN Управление резервными копированиями
BINLOG_ADMIN Управление резервными копиями и репликацией
BINLOG_ENCRYPTION_ADMIN Управление резервными копиями и репликацией
CLONE_ADMIN Управление клонированием
CONNECTION_ADMIN Управление сервером
CREATE_SPATIAL_REFERENCE_SYSTEM Управление ГИС
ENCRYPTION_KEY_ADMIN Управление сервером
EXPORT_QUERY_RESULTS Разрешить пользователю экспортировать результаты запроса
FIREWALL_ADMIN Управление брандмауэром
FIREWALL_EXEMPT Управление брандмауэром
FIREWALL_USER Управление брандмауэром
FLUSH_OPTIMIZER_COSTS Управление сервером
FLUSH_PRIVILEGES (Устарело) Управление сервером
FLUSH_STATUS Управление сервером
FLUSH_TABLES Управление сервером
FLUSH_USER_RESOURCES Управление сервером
GROUP_REPLICATION_ADMIN Управление репликацией
GROUP_REPLICATION_STREAM Управление репликацией
INNODB_REDO_LOG_ARCHIVE Управление архивированием журнала редо
INNODB_REDO_LOG_ENABLE Управление журналом редо
MASKING_DICTIONARIES_ADMIN Управление сервером
NDB_STORED_USER Кластер NDB
OPTIMIZE_LOCAL_TABLE OPTIMIZE LOCAL TABLE
OPTION_TRACKER_UPDATER Доступ для записи в таблицу Option Tracker mysql_option.option_usage
PASSWORDLESS_USER_ADMIN Управление аутентификацией
PERSIST_RO_VARIABLES_ADMIN Управление сервером
REPLICATION_APPLIER PRIVILEGE_CHECKS_USER для канала репликации
REPLICATION_SLAVE_ADMIN Управление репликацией
RESOURCE_GROUP_ADMIN Управление группой ресурсов
RESOURCE_GROUP_USER Управление группой ресурсов
ROLE_ADMIN Управление сервером
SENSITIVE_VARIABLES_OBSERVER Управление сервером
SESSION_VARIABLES_ADMIN Управление сервером
SET_ANY_DEFINER Управление сервером
SHOW_ROUTINE Управление сервером
SKIP_QUERY_REWRITE Управление сервером
SYSTEM_USER Управление сервером
SYSTEM_VARIABLES_ADMIN Управление сервером
TABLE_ENCRYPTION_ADMIN Управление сервером
TELEMETRY_LOG_ADMIN Управление журналом телеметрии для HeatWave на AWS
TP_CONNECTION_ADMIN Управление пулом потоков
TRANSACTION_GTID_TAG Управление репликацией
VERSION_TOKEN_ADMIN (Устарело) Управление сервером
XA_RECOVER_ADMIN Управление сервером

Статические описания привилегий

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

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

  • ALL, ALL PRIVILEGES

    Эти спецификаторы привилегий являются сокращением для “всех привилегий, доступных на данном уровне привилегий” (за исключением GRANT OPTION). Например, предоставление ALL на глобальном или табличном уровне предоставляет все глобальные привилегии или все привилегии уровня таблицы соответственно.

  • ALTER

    Позволяет использовать оператор ALTER TABLE для изменения структуры таблиц. ALTER TABLE также требует привилегий CREATE и INSERT. Переименование таблицы требует ALTER и DROP для старой таблицы, CREATE и INSERT для новой таблицы.

  • ALTER ROUTINE

    Позволяет использовать операторы, которые изменяют или удаляют хранимые процедуры (хранимые процедуры и функции). Для процедур, которые попадают в область действия, в которой предоставлена привилегия, и для которых пользователь не является пользователем, указанным в качестве владельца процедуры DEFINER, также обеспечивает доступ к свойствам процедуры, отличным от определения процедуры.

  • CREATE

    Позволяет использовать операторы, которые создают новые базы данных и таблицы.

  • CREATE ROLE

    Позволяет использовать оператор CREATE ROLE. (Привилегия CREATE USER также позволяет использовать оператор CREATE ROLE.) См. Раздел 8.2.10, «Использование ролей».

    Привилегии CREATE ROLE и DROP ROLE не так сильны, как CREATE USER, поскольку они могут использоваться только для создания и удаления учетных записей. Их нельзя использовать так, как CREATE USER, чтобы изменять атрибуты учетной записи или переименовывать учетные записи. См. Взаимозаменяемость пользователей и ролей.

  • CREATE ROUTINE

    Позволяет использовать операторы, которые создают хранимые процедуры (хранимые процедуры и функции). Для процедур, которые попадают в область действия, в которой предоставлена привилегия, и для которых пользователь не является пользователем, указанным в качестве владельца процедуры DEFINER, также обеспечивает доступ к свойствам процедуры, отличным от определения процедуры.

  • CREATE TABLESPACE

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

  • CREATE TEMPORARY TABLES

    Позволяет создавать временные таблицы с помощью оператора CREATE TEMPORARY TABLE.

    После того, как сеанс создал временную таблицу, сервер больше не выполняет проверку привилегий для таблицы. Создающий сеанс может выполнять любую операцию с таблицей, например DROP TABLE, INSERT, UPDATE или SELECT. Для получения дополнительной информации см. Раздел 15.1.21.2, «Оператор CREATE TEMPORARY TABLE».

  • CREATE USER

    Позволяет использовать операторы ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, RENAME USER и REVOKE ALL PRIVILEGES.

  • CREATE VIEW

    Позволяет использовать оператор CREATE VIEW.

  • DELETE

    Позволяет удалять строки из таблиц в базе данных.

  • DROP

    Позволяет использовать операторы, которые удаляют (удаляют) существующие базы данных, таблицы и представления. Привилегия DROP необходима для использования оператора ALTER TABLE ... DROP PARTITION для секционированной таблицы. Привилегия DROP также необходима для TRUNCATE TABLE.

  • DROP ROLE

    Позволяет использовать оператор DROP ROLE. (Привилегия CREATE USER также позволяет использовать оператор DROP ROLE.) См. Раздел 8.2.10, «Использование ролей».

    Привилегии CREATE ROLE и DROP ROLE не так сильны, как CREATE USER, поскольку они могут использоваться только для создания и удаления учетных записей. Их нельзя использовать так, как CREATE USER, чтобы изменять атрибуты учетной записи или переименовывать учетные записи. См. Взаимозаменяемость пользователей и ролей.

  • EVENT

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

  • EXECUTE

    Позволяет использовать операторы, которые выполняют хранимые процедуры (хранимые процедуры и функции). Для процедур, которые попадают в область действия, в которой предоставлена привилегия, и для которых пользователь не является пользователем, указанным в качестве владельца процедуры DEFINER, также обеспечивает доступ к свойствам процедуры, отличным от определения процедуры.

  • FILE

    Влияет на следующие операции и поведение сервера:

    • Позволяет читать и записывать файлы на хосте сервера с использованием операторов LOAD DATA и SELECT ... INTO OUTFILE и функции LOAD_FILE(). Пользователь, имеющий привилегию FILE, может читать любой файл на хосте сервера, который является общедоступным для чтения или доступным для чтения сервером MySQL. (Это подразумевает, что пользователь может читать любой файл в любом каталоге базы данных, поскольку сервер может получить доступ к любому из этих файлов.)

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

    • Позволяет использовать параметр таблицы DATA DIRECTORY или INDEX DIRECTORY для оператора CREATE TABLE.

    В качестве меры безопасности сервер не перезаписывает существующие файлы.

    Чтобы ограничить местоположение, в котором можно читать и записывать файлы, установите системную переменную secure_file_priv в определенный каталог. См. Раздел 7.1.8, «Системные переменные сервера».

  • GRANT OPTION

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

  • Индексные привилегии

    Разрешает использование операторов, создающих или удаляющих индексы. Привилегия INDEX применяется к существующим таблицам. Если у вас есть привилегия CREATE для таблицы, вы можете включить определения индексов в операторе CREATE TABLE.

  • Привилегия вставки

    Разрешает вставку строк в таблицы базы данных. Привилегия INSERT также требуется для операторов обслуживания таблиц ANALYZE TABLE, OPTIMIZE TABLE и REPAIR TABLE.

  • Привилегия блокировки таблиц

    Разрешает использование явных операторов LOCK TABLES для блокировки таблиц, для которых у вас есть привилегия SELECT. Это включает использование блокировок на запись, которые предотвращают чтение заблокированной таблицы другими сеансами.

  • Привилегия доступа к информации о потоках

    Привилегия PROCESS контролирует доступ к информации о потоках, выполняемых внутри сервера (т.е. информацию о выполняемых операторах сеансами). Информация о потоках, доступная с помощью оператора SHOW PROCESSLIST, команды mysqladmin processlist, таблицы схемы информации PROCESSLIST и таблицы схемы производительности processlist, доступна следующим образом:

    • При наличии привилегии PROCESS пользователь имеет доступ к информации обо всех потоках, даже принадлежащих другим пользователям.

    • Без привилегии PROCESS неанонимные пользователи имеют доступ к информации о своих потоках, но не о потоках других пользователей, а анонимные пользователи не имеют доступа к информации о потоках.

    Примечание

    Таблица схемы производительности threads также предоставляет информацию о потоках, но доступ к таблицам использует другую модель привилегий. См. Раздел 29.12.22.9, «Таблица threads».

    Привилегия PROCESS также разрешает использование оператора SHOW ENGINE, доступ к таблицам INFORMATION_SCHEMA InnoDB (таблицам с именами, начинающимися с INNODB_) и доступ к таблице INFORMATION_SCHEMA FILES.

  • Привилегия проксирования

    Разрешает одному пользователю представлять или быть известным как другой пользователь. См. Раздел 8.2.19, «Пользователи-прокси».

  • Привилегии ссылок

    Для создания внешнего ключа требуется привилегия REFERENCES для родительской таблицы.

  • Привилегия перезагрузки

    Привилегия RELOAD разрешает следующие операции:

    • Использование оператора FLUSH.

    • Использование команд mysqladmin, эквивалентных операциям FLUSH: flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, refresh и reload.

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

    • Использование опций mysqldump, выполняющих различные операции FLUSH: --flush-logs и --source-data.

    • Использование операторов RESET BINARY LOGS AND GTIDS и RESET REPLICA.

  • Привилегия клиента репликации

    Разрешает использование операторов SHOW BINARY LOG STATUS, SHOW REPLICA STATUS и SHOW BINARY LOGS.

  • Привилегия сервера репликации

    Разрешает учетной записи запрашивать обновления, внесённые в базы данных на сервере репликации, с помощью операторов SHOW REPLICAS, SHOW RELAYLOG EVENTS и SHOW BINLOG EVENTS. Эта привилегия также необходима для использования опций mysqlbinlog --read-from-remote-server (-R) и --read-from-remote-source. Предоставьте эту привилегию учётным записям, используемым репликами для подключения к текущему серверу в качестве их сервера репликации.

  • Привилегия выбора

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

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

    Привилегия SELECT также необходима для других операторов, которые считывают значения столбцов. Например, SELECT необходима для столбцов, упоминаемых в правой части присваивания col_name=expr в операторах UPDATE или для столбцов, перечисленных в предложении WHERE операторов DELETE или UPDATE.

    Привилегия SELECT необходима для таблиц или представлений, используемых с EXPLAIN, включая любые основанные таблицы в определениях представлений.

  • SHOW DATABASES

    Разрешает учетной записи просматривать имена баз данных, выполняя операцию SHOW DATABASE. Учетные записи, не имеющие этого права, видят только базы данных, для которых у них есть какие-либо права, и не могут вообще использовать эту операцию, если сервер был запущен с опцией --skip-show-database.

    Предупреждение

    Поскольку любое статическое глобальное право считается правом для всех баз данных, любое статическое глобальное право позволяет пользователю видеть все имена баз данных с помощью SHOW DATABASES или путем проверки таблицы SCHEMATA таблицы INFORMATION_SCHEMA, за исключением баз данных, которые были ограничены на уровне базы данных частичными отзывами прав.

  • SHOW VIEW

    Разрешает использование операции SHOW CREATE VIEW. Это право также необходимо для представлений, используемых с EXPLAIN.

  • SHUTDOWN

    Разрешает использование операций SHUTDOWN и RESTART, команду mysqladmin shutdown и функцию C API.

  • SUPER

    SUPER — это мощное и широкодействующее право, которое не следует предоставлять легкомысленно. Если учетной записи требуется выполнить только подмножество операций SUPER, возможно, можно получить желаемый набор прав, предоставив одно или несколько динамических прав, каждое из которых предоставляет более ограниченные возможности. См. Описание динамических прав.

    Примечание

    SUPER устарело и ожидается, что оно будет удалено в будущих версиях MySQL. См. Перенос учетных записей с SUPER на динамические права.

    SUPER влияет на следующие операции и поведение сервера:

    • Разрешает изменения переменных системы во время выполнения:

      • Разрешает изменения конфигурации сервера для глобальных системных переменных с помощью SET GLOBAL и SET PERSIST.

        Соответствующее динамическое право — SYSTEM_VARIABLES_ADMIN.

      • Разрешает установку ограниченных сеансовых системных переменных, требующих специального права.

        Соответствующее динамическое право — SESSION_VARIABLES_ADMIN.

      См. также Раздел 7.1.9.1, «Права на системные переменные».

    • Разрешает изменения глобальных характеристик транзакций (см. Раздел 15.3.7, «Операция SET TRANSACTION»).

      Соответствующее динамическое право — SYSTEM_VARIABLES_ADMIN.

    • Разрешает учетной записи запускать и останавливать репликацию, включая Group Replication.

      Соответствующее динамическое право — REPLICATION_SLAVE_ADMIN для обычной репликации, GROUP_REPLICATION_ADMIN для Group Replication.

    • Разрешает использовать операцию CHANGE REPLICATION SOURCE TO и CHANGE REPLICATION FILTER.

      Соответствующее динамическое право — REPLICATION_SLAVE_ADMIN.

    • Разрешает управление бинарными логами с помощью операций PURGE BINARY LOGS и BINLOG.

      Соответствующее динамическое право — BINLOG_ADMIN.

    • Разрешает установить действительный идентификатор авторизации при выполнении представления или хранимой программы. Пользователь с этим правом может указать любую учетную запись в атрибуте DEFINER представления или хранимой программы.

      Соответствующие динамические права — SET_ANY_DEFINER и ALLOW_NONEXISTENT_DEFINER.

    • Разрешает использование операций CREATE SERVER, ALTER SERVER и DROP SERVER.

    • Разрешает использование команды mysqladmin debug.

    • Разрешает вращение ключей шифрования InnoDB.

      Соответствующее динамическое право — ENCRYPTION_KEY_ADMIN.

    • Разрешает выполнение устаревших функций Version Tokens.

      Соответствующее динамическое право — VERSION_TOKEN_ADMIN, которое устарело в MySQL 9.2.0.

    • Разрешает назначение и отзыв ролей, использование фразы WITH ADMIN OPTION оператора GRANT и непустое содержание элемента <graphml> в результате работы функции ROLES_GRAPHML().

      Соответствующее динамическое право — ROLE_ADMIN.

    • Разрешает контроль над клиентскими подключениями, запрещенными для учетных записей, не имеющих права SUPER:

      • Разрешает использование операции KILL или команды mysqladmin kill для завершения потоков, принадлежащих другим учетным записям. (Учетная запись всегда может завершать свои собственные потоки.)

      • Сервер не выполняет содержимое системной переменной init_connect при подключении клиентов с правом SUPER.

      • Сервер принимает одно подключение от клиента с правом SUPER, даже если предел подключений, настроенный системной переменной max_connections, достигнут.

      • Сервер в режиме автономного режима (offline_mode включен) не завершает подключения клиентов с правом SUPER при следующем запросе клиента и принимает новые подключения от клиентов с правом SUPER.

      • Обновления могут выполняться даже при включении системной переменной read_only. Это относится к явным обновлениям таблиц и к использованию операторов управления учетными записями, таких как GRANT и REVOKE, которые неявно обновляют таблицы.

      Соответствующее динамическое право для предыдущих операций управления подключениями — CONNECTION_ADMIN.

    Вам также может потребоваться право SUPER для создания или изменения хранимых функций, если включена запись в бинарный журнал, как описано в Разделе 27.8, «Логирование хранимых программ в бинарном формате».

  • TRIGGER

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

    Когда триггер активируется (пользователем, имеющим права на выполнение инструкций INSERT, UPDATE или DELETE для таблицы, связанной с триггером), для выполнения триггера требуется, чтобы пользователь, определивший триггер, по-прежнему имел право TRIGGER для таблицы.

  • UPDATE

    Позволяет обновлять строки в таблицах базы данных.

  • USAGE

    Этот спецификатор привилегий означает “отсутствие прав.” Он используется на глобальном уровне с GRANT для указания таких разделов, как WITH GRANT OPTION, без указания конкретных прав учетной записи в списке прав. SHOW GRANTS отображает USAGE, чтобы указать, что учетная запись не имеет прав на определенном уровне прав.

Описания динамических привилегий

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

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

Конкретные операторы SQL могут иметь более специфические требования к привилегиям, чем указано здесь. Если это так, описание соответствующего оператора содержит подробные сведения.

  • ALLOW_NONEXISTENT_DEFINER

    Позволяет переопределять проверки безопасности, предназначенные для предотвращения операций, которые (возможно, непреднамеренно) приводят к тому, что хранимые объекты становятся осиротевшими или приводят к усыновлению хранимых объектов, которые в настоящее время являются осиротевшими. Без этой привилегии любая попытка создать осиротевшую SQL-процедуру, функцию или представление приводит к ошибке. Попытка создать осиротевшие объекты с помощью CREATE PROCEDURE, CREATE FUNCTION, CREATE TRIGGER, CREATE EVENT или CREATE VIEW также требует SET_ANY_DEFINER в дополнение к ALLOW_NONEXISTENT_DEFINER, так что определяющий элемент, отличный от текущего пользователя, допустим.

    Подробнее см. Осиротевшие хранимые объекты.

  • APPLICATION_PASSWORD_ADMIN

    Для возможности двойного пароля эта привилегия позволяет использовать разделы RETAIN CURRENT PASSWORD и DISCARD OLD PASSWORD для операторов ALTER USER и SET PASSWORD, которые применяются к вашей собственной учетной записи. Эта привилегия необходима для управления собственным вторичным паролем, поскольку большинству пользователей требуется только один пароль.

    Если учетной записи разрешено управлять вторичными паролями для всех учетных записей, ей следует предоставить привилегию CREATE USER, а не APPLICATION_PASSWORD_ADMIN.

    Для получения дополнительной информации об использовании двойных паролей см. Раздел 8.2.15, «Управление паролями».

  • AUDIT_ABORT_EXEMPT

    Позволяет выполнять запросы, блокируемые элементом “abort” в фильтре журнала аудита. Эта привилегия определяется плагином audit_log; см. Раздел 8.4.5, «Аудит MySQL Enterprise».

    Учетные записи, созданные с привилегией SYSTEM_USER, автоматически получают привилегию AUDIT_ABORT_EXEMPT при создании. Привилегия AUDIT_ABORT_EXEMPT также назначается существующим учетным записям с привилегией SYSTEM_USER при выполнении процедуры обновления, если ни одна из существующих учетных записей не имеет этой привилегии. Таким образом, учетные записи с привилегией SYSTEM_USER могут использоваться для восстановления доступа к системе после неправильной настройки аудита.

  • AUDIT_ADMIN

    Включает конфигурацию журнала аудита. Эта привилегия определяется плагином audit_log; см. Раздел 8.4.5, «Аудит MySQL Enterprise».

  • BACKUP_ADMIN

    Включает выполнение оператора LOCK INSTANCE FOR BACKUP и доступ к таблице log_status схемы производительности.

    Примечание

    Помимо BACKUP_ADMIN, для доступа к ней также необходима привилегия SELECT для таблицы log_status.

    Привилегия BACKUP_ADMIN автоматически предоставляется пользователям с привилегией RELOAD при выполнении обновления на месте до MySQL 9.2 из более ранней версии.

  • AUTHENTICATION_POLICY_ADMIN

    Системная переменная authentication_policy накладывает определенные ограничения на то, как могут использоваться разделы, связанные с аутентификацией, операторов CREATE USER и ALTER USER. Пользователь, имеющий привилегию AUTHENTICATION_POLICY_ADMIN, не подчиняется этим ограничениям. (Предупреждение возникает для операторов, которые в противном случае не были бы разрешены.)

    Подробные сведения об ограничениях, налагаемых authentication_policy, см. в описании этой переменной.

  • BINLOG_ADMIN

    Включает управление двоичным журналом с помощью операторов PURGE BINARY LOGS и BINLOG.

  • BINLOG_ENCRYPTION_ADMIN

    Позволяет устанавливать системную переменную binlog_encryption, которая активирует или деактивирует шифрование для файлов двоичных журналов и файлов журналов ретрансляции. Эта возможность не предоставляется привилегиями BINLOG_ADMIN, SYSTEM_VARIABLES_ADMIN или SESSION_VARIABLES_ADMIN. Для связанной системной переменной binlog_rotate_encryption_master_key_at_startup, которая автоматически поворачивает главный ключ двоичного журнала при перезапуске сервера, эта привилегия не требуется.

  • CLONE_ADMIN

    Включает выполнение операторов CLONE. Включает привилегии BACKUP_ADMIN и SHUTDOWN.

  • CONNECTION_ADMIN

    Разрешает использование оператора KILL или команды mysqladmin kill для завершения потоков, принадлежащих другим учётным записям. (Учётная запись всегда может завершать свои собственные потоки.)

    Разрешает установку системных переменных, связанных с клиентскими подключениями, или обход ограничений, связанных с клиентскими подключениями. Для активации автономного режима MySQL Server требуется CONNECTION_ADMIN, что выполняется путём изменения значения системной переменной offline_mode на ON.

    Привилегия CONNECTION_ADMIN позволяет администраторам, обладающим ею, обойти действие этих системных переменных:

    • init_connect: сервер не выполняет содержимое системной переменной init_connect при подключении клиентов с привилегией CONNECTION_ADMIN.

    • max_connections: сервер принимает одно подключение от клиента с привилегией CONNECTION_ADMIN, даже если предел подключений, настроенный системной переменной max_connections, достигнут.

    • offline_mode: сервер в автономном режиме (offline_mode включен) не завершает подключения клиентов с привилегией CONNECTION_ADMIN при следующем запросе клиента и принимает новые подключения от клиентов с привилегией CONNECTION_ADMIN.

    • read_only: обновления от клиентов с привилегией CONNECTION_ADMIN могут выполняться даже при включении системной переменной read_only. Это относится к явным обновлениям таблиц и к операторам управления учётными записями, таким как GRANT и REVOKE, которые неявно обновляют таблицы.

    Члены группы репликации Group Replication нуждаются в привилегии CONNECTION_ADMIN, чтобы подключения Group Replication не завершались, если один из участвующих серверов переведён в автономный режим. Если используется стек MySQL-связи (group_replication_communication_stack = MYSQL), без этой привилегии участник, переведённый в автономный режим, исключается из группы.

  • CREATE_SPATIAL_REFERENCE_SYSTEM

    Разрешает использование операторов CREATE SPATIAL REFERENCE SYSTEM, CREATE OR REPLACE SPATIAL REFERENCE SYSTEM и DROP SPATIAL REFERENCE SYSTEM. Попытка выполнить любой из этих операторов без этой привилегии (или привилегии SUPER) теперь вызывает ошибку.

    Добавлено в MySQL 9.2.0; использование этой привилегии предназначено для замены использования привилегии SUPER в этих целях, которое следует считать устаревшим.

  • ENCRYPTION_KEY_ADMIN

    Разрешает InnoDB вращение ключей шифрования.

  • EXPORT_QUERY_RESULTS

    Разрешает пользователю экспортировать результаты запросов в хранилище объектов OCI или AWS.

    Применимо только к MySQL HeatWave.

  • FIREWALL_ADMIN

    Разрешает пользователю управлять правилами брандмауэра для любого пользователя. Эта привилегия определена плагином MYSQL_FIREWALL; см. Раздел 8.4.7, «MySQL Enterprise Firewall».

  • FIREWALL_EXEMPT

    Пользователь с этой привилегией освобождён от ограничений брандмауэра. Эта привилегия определена плагином MYSQL_FIREWALL; см. Раздел 8.4.7, «MySQL Enterprise Firewall».

  • FIREWALL_USER

    Разрешает пользователям обновлять свои собственные правила брандмауэра. Эта привилегия определена плагином MYSQL_FIREWALL; см. Раздел 8.4.7, «MySQL Enterprise Firewall».

  • FLUSH_OPTIMIZER_COSTS

    Разрешает использование оператора FLUSH OPTIMIZER_COSTS.

  • FLUSH_PRIVILEGES

    Разрешает использование оператора FLUSH PRIVILEGES.

    Устарело начиная с MySQL 9.2.0, наряду с оператором FLUSH PRIVILEGES; ожидается, что эта привилегия будет удалена в будущей версии MySQL. В MySQL 9.2.0 и более поздних версиях предоставление привилегии FLUSH_PRIVILEGES вызывает предупреждение об устаревании.

  • FLUSH_STATUS

    Разрешает использование оператора FLUSH STATUS.

  • FLUSH_TABLES

    Разрешает использование оператора FLUSH TABLES.

  • FLUSH_USER_RESOURCES

    Разрешает использование оператора FLUSH USER_RESOURCES.

  • GROUP_REPLICATION_ADMIN

    Разрешает учётной записи запускать и останавливать Group Replication с помощью операторов START GROUP REPLICATION и STOP GROUP REPLICATION, изменять глобальную настройку системной переменной group_replication_consistency и использовать функции group_replication_set_write_concurrency() и group_replication_set_communication_protocol(). Предоставьте эту привилегию учётным записям, используемым для администрирования серверов, которые являются членами группы репликации.

  • GROUP_REPLICATION_STREAM

    Разрешает использовать учётную запись для установления соединений групповой связи Group Replication. Она должна быть предоставлена пользователю восстановления, когда для Group Replication используется стек MySQL-связи (group_replication_communication_stack=MYSQL).

  • INNODB_REDO_LOG_ARCHIVE

    Разрешает учётной записи активировать и деактивировать архивирование журнала redo.

  • INNODB_REDO_LOG_ENABLE

    Разрешает использование оператора ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG для включения или отключения журналирования redo.

    См. Отключение журналирования redo.

  • MASKING_DICTIONARIES_ADMIN

    Разрешает учётной записи добавлять и удалять термины словаря с помощью компонентных функций masking_dictionary_term_add() и masking_dictionary_term_remove(). Учётные записи также требуют этой динамической привилегии для удаления полного словаря с помощью функции masking_dictionary_remove(), которая удаляет все термины, связанные с указанным словарем, в настоящее время в таблице mysql.masking_dictionaries.

    См. Раздел 8.5, «MySQL Enterprise Data Masking and De-Identification».

  • NDB_STORED_USER

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

    Любые изменения или отмены привилегий, внесенные для данного пользователя или роли, немедленно синхронизируются со всеми подключенными серверами MySQL (SQL-узлами). Следует помнить, что нет гарантии, что несколько операторов, влияющих на привилегии и исходящих от разных SQL-узлов, выполняются на всех SQL-узлах в одном и том же порядке. По этой причине настоятельно рекомендуется выполнять все операции администрирования пользователей с одного назначенного SQL-узла.

    NDB_STORED_USER является глобальной привилегией и должна предоставляться или отзываться с использованием ON *.*. Попытка установить любой другой диапазон для этой привилегии приводит к ошибке. Эта привилегия может быть предоставлена большинству пользователей приложений и администраторов, но она не может быть предоставлена зарезервированным системным учетным записям, таким как mysql.session@localhost или mysql.infoschema@localhost.

    Пользователь, которому предоставлена привилегия NDB_STORED_USER, хранится в NDB (и, таким образом, совместно используется всеми SQL-узлами), как и роль с этой привилегией. Пользователь, которому просто предоставлена роль, имеющая NDB_STORED_USER, не хранится в NDB; каждому хранимому пользователю NDB необходимо явно предоставить привилегию.

    Для получения более подробной информации о том, как это работает в NDB, см. Раздел 25.6.13, «Синхронизация привилегий и NDB_STORED_USER».

  • OPTIMIZE_LOCAL_TABLE

    Позволяет использовать операторы OPTIMIZE LOCAL TABLE и OPTIMIZE NO_WRITE_TO_BINLOG TABLE.

  • OPTION_TRACKER_UPDATER

    Эта привилегия необходима для записи в таблицу mysql_option.option_usage; как привилегия, так и таблица предоставляются компонентом Option Tracker. Для получения дополнительной информации см. Раздел 7.5.9, «Компонент Option Tracker».

  • PASSWORDLESS_USER_ADMIN

    Эта привилегия применяется к учетным записям пользователей без пароля:

    • Для создания учетной записи пользователь, который выполняет команду CREATE USER для создания учетной записи без пароля, должен обладать привилегией PASSWORDLESS_USER_ADMIN.

    • В контексте репликации привилегия PASSWORDLESS_USER_ADMIN применяется к пользователям репликации и позволяет реплицировать операторы ALTER USER ... MODIFY для учетных записей пользователей, настроенных для аутентификации без пароля.

    Информация об аутентификации без пароля см. Аутентификация без пароля WebAuthn.

  • PERSIST_RO_VARIABLES_ADMIN

    Для пользователей, которые также имеют SYSTEM_VARIABLES_ADMIN, PERSIST_RO_VARIABLES_ADMIN позволяет использовать SET PERSIST_ONLY для сохранения глобальных системных переменных в файл опций mysqld-auto.cnf в каталоге данных. Этот оператор похож на SET PERSIST, но не изменяет значение глобальной системной переменной во время выполнения. Это делает SET PERSIST_ONLY подходящим для настройки системных переменных только для чтения, которые могут быть установлены только при запуске сервера.

    См. также Раздел 7.1.9.1, «Привилегии системных переменных».

  • REPLICATION_APPLIER

    Позволяет учетной записи выступать в качестве PRIVILEGE_CHECKS_USER для канала репликации и выполнять операторы BINLOG в выводе mysqlbinlog. Предоставьте эту привилегию учетным записям, которые назначены с помощью CHANGE REPLICATION SOURCE TO, чтобы обеспечить контекст безопасности для каналов репликации и обрабатывать ошибки репликации на этих каналах. Помимо привилегии REPLICATION_APPLIER, вы также должны предоставить учетной записи необходимые привилегии для выполнения транзакций, полученных каналом репликации или содержащихся в выводе mysqlbinlog, например, для обновления затронутых таблиц. Для получения дополнительной информации см. Раздел 19.3.3, «Проверка привилегий репликации».

  • REPLICATION_SLAVE_ADMIN

    Позволяет учетной записи подключаться к серверу источника репликации, запускать и останавливать репликацию с помощью операторов START REPLICA и STOP REPLICA, а также использовать операторы CHANGE REPLICATION SOURCE TO и CHANGE REPLICATION FILTER. Предоставьте эту привилегию учетным записям, используемым репликами для подключения к текущему серверу в качестве сервера источника репликации. Эта привилегия не применяется к групповой репликации; используйте GROUP_REPLICATION_ADMIN для этого.

  • RESOURCE_GROUP_ADMIN

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

  • RESOURCE_GROUP_USER

    Позволяет назначать потоки и операторы группам ресурсов. Пользователь с этой привилегией может использовать оператор SET RESOURCE GROUP и подсказку оптимизатора RESOURCE_GROUP.

  • ROLE_ADMIN

    Позволяет предоставлять и отзывать роли, использовать предложение WITH ADMIN OPTION оператора GRANT и непустое содержимое элемента <graphml> в результате работы функции ROLES_GRAPHML(). Необходимо для установки значения системной переменной mandatory_roles.

  • SENSITIVE_VARIABLES_OBSERVER

    Позволяет владельцу просматривать значения конфиденциальных системных переменных в таблицах Performance Schema global_variables, session_variables, variables_by_thread и persisted_variables, для выдачи операторов SELECT для возврата их значений и отслеживания изменений в них в средствах отслеживания сеансов для подключений. Пользователи без этой привилегии не могут просматривать или отслеживать эти значения системных переменных. См. Сохранение конфиденциальных системных переменных.

  • SERVICE_CONNECTION_ADMIN

    Позволяет подключения к сетевому интерфейсу, который разрешает только административные подключения (см. Раздел 7.1.12.1, «Интерфейсы подключения»).

  • SESSION_VARIABLES_ADMIN

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

    Если системная переменная ограничена и для установки значения сессии требуется специальная привилегия, то это ограничение указано в описании переменной. Примерами являются binlog_format, sql_log_bin и sql_log_off.

    Привилегия SESSION_VARIABLES_ADMIN является подмножеством привилегий SYSTEM_VARIABLES_ADMIN и SUPER. Пользователь, обладающий любой из этих привилегий, также имеет право устанавливать ограниченные переменные сессии и, по умолчанию, обладает привилегией SESSION_VARIABLES_ADMIN, и ему не нужно явно предоставлять привилегию SESSION_VARIABLES_ADMIN.

    См. также Раздел 7.1.9.1, «Привилегии системных переменных».

  • SET_ANY_DEFINER

    Позволяет установить эффективный идентификатор авторизации при выполнении представления или хранимой процедуры. Пользователь с этой привилегией может указать любой аккаунт как атрибут DEFINER для CREATE PROCEDURE, CREATE FUNCTION, CREATE TRIGGER, CREATE EVENT, ALTER EVENT, CREATE VIEW и ALTER VIEW. Без этой привилегии можно указать только эффективный идентификатор аутентификации.

    Хранимые программы выполняются с привилегиями указанного аккаунта, поэтому убедитесь, что вы следуете рекомендациям по минимизации рисков, перечисленным в Разделе 27.7, «Управление доступом к хранимым объектам».

  • SHOW_ROUTINE

    Позволяет пользователю получить доступ к определениям и свойствам всех хранимых процедур (хранимых процедур и функций), даже тех, для которых пользователь не указан как автор хранимой процедуры. Этот доступ включает в себя:

    • Содержимое таблицы схемы Information Schema ROUTINES.

    • Команды SHOW CREATE FUNCTION и SHOW CREATE PROCEDURE.

    • Команды SHOW FUNCTION CODE и SHOW PROCEDURE CODE.

    • Команды SHOW FUNCTION STATUS и SHOW PROCEDURE STATUS.

    Привилегия SHOW_ROUTINE может быть предоставлена вместо привилегии с более ограниченным объемом, разрешающей доступ к определениям процедур. (То есть администратор может отозвать глобальную привилегию SELECT у пользователей, которым она не требуется, и предоставить вместо этого привилегию SHOW_ROUTINE). Это позволяет аккаунту создавать резервные копии хранимых процедур без необходимости широких привилегий.

  • SKIP_QUERY_REWRITE

    Запросы, выпущенные пользователем с этой привилегией, не будут переписываться плагином Rewriter (см. Раздел 7.6.4, «Плагин переписывания запросов Rewriter»).

    Эту привилегию следует предоставлять пользователям, которые выпускают административные или управляющие запросы, которые не должны переписываться, а также аккаунтам PRIVILEGE_CHECKS_USER (см. Раздел 19.3.3, «Проверка привилегий репликации»), используемым для применения запросов из источника репликации.

  • SYSTEM_USER

    Привилегия SYSTEM_USER отличает системных пользователей от обычных пользователей:

    • Пользователь с привилегией SYSTEM_USER является системным пользователем.

    • Пользователь без привилегии SYSTEM_USER является обычным пользователем.

    Привилегия SYSTEM_USER влияет на аккаунты, к которым данный пользователь может применять свои другие привилегии, а также на защиту пользователя от других аккаунтов:

    • Системный пользователь может изменять как системные, так и обычные аккаунты. То есть, пользователь, обладающий соответствующими привилегиями для выполнения операции с обычными аккаунтами, благодаря наличию привилегии SYSTEM_USER, также может выполнить эту операцию с системными аккаунтами. Системный аккаунт может быть изменён только системными пользователями с соответствующими привилегиями, а не обычными пользователями.

    • Обычный пользователь с соответствующими привилегиями может изменять обычные аккаунты, но не системные аккаунты. Обычный аккаунт может быть изменён как системными, так и обычными пользователями с соответствующими привилегиями.

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

    Более подробная информация приведена в Разделе 8.2.11, «Категории аккаунтов».

    Защита системных аккаунтов от изменения обычными аккаунтами, предоставляемая привилегией SYSTEM_USER, не распространяется на обычные аккаунты, имеющие привилегии на схеме mysql системы и, следовательно, могут напрямую изменять таблицы грантов в этой схеме. Для полной защиты не предоставляйте привилегии схемы mysql обычным аккаунтам. См. Защиту системных аккаунтов от манипуляций обычными аккаунтами.

    Если используется плагин audit_log (см. Раздел 8.4.5, «Аудит MySQL Enterprise»), аккаунтам с привилегией SYSTEM_USER автоматически назначается привилегия AUDIT_ABORT_EXEMPT, которая разрешает выполнение их запросов, даже если элемент “abort”, настроенный в фильтре, их заблокирует. Аккаунты с привилегией SYSTEM_USER могут поэтому быть использованы для восстановления доступа к системе после неправильной настройки аудита.

  • SYSTEM_VARIABLES_ADMIN

    Воздействует на следующие операции и поведение сервера:

    • Включает изменения переменных системы во время выполнения:

      • Включает изменения конфигурации сервера для глобальных переменных системы с помощью SET GLOBAL и SET PERSIST.

      • Включает изменения конфигурации сервера для глобальных переменных системы с помощью SET PERSIST_ONLY, если у пользователя также есть PERSIST_RO_VARIABLES_ADMIN.

      • Включает установку ограниченных переменных сеанса системы, требующих специального права. Фактически, SYSTEM_VARIABLES_ADMIN подразумевает SESSION_VARIABLES_ADMIN без явного предоставления SESSION_VARIABLES_ADMIN.

      См. также Раздел 7.1.9.1, «Права на переменные системы».

    • Включает изменения глобальных характеристик транзакции (см. Раздел 15.3.7, «Управление транзакцией»).

  • TABLE_ENCRYPTION_ADMIN

    Позволяет пользователю переопределять параметры шифрования по умолчанию, когда table_encryption_privilege_check включено; см. Определение шифрования по умолчанию для схем и общих табличных пространств.

  • TELEMETRY_LOG_ADMIN

    Включает настройку журнала телеметрии. Это право определяется плагином telemetry_log, который развертывается через HeatWave на AWS.

  • TP_CONNECTION_ADMIN

    Включает подключение к серверу с привилегированным подключением. Когда предел, определенный thread_pool_max_transactions_limit достигнут, новые подключения не допускаются, если не переопределены thread_pool_longrun_trx_limit. Привилегированное подключение игнорирует лимит транзакций и разрешает подключиться к серверу для увеличения лимита транзакций, удаления ограничения или завершения выполнения транзакций. По умолчанию это право никому не предоставляется. Чтобы установить привилегированное подключение, пользователь, инициирующий подключение, должен иметь право TP_CONNECTION_ADMIN.

    Привилегированное подключение может выполнять инструкции и запускать транзакции, когда достигнут предел, определенный thread_pool_max_transactions_limit. Привилегированное подключение помещается в группу потоков Admin. См. Привилегированные подключения.

  • TRANSACTION_GTID_TAG

    Требуется для установки переменной системы gtid_next на значение AUTOMATIC:TAG или UUID:TAG:NUMBER на сервере источника репликации. Кроме того, требуется как минимум одно из SYSTEM_VARIABLES_ADMIN, SESSION_VARIABLES_ADMIN или REPLICATION_APPLIER для установки gtid_next на одно из этих значений на источнике.

    REPLICATION_CHECKS_APPLIER также должен иметь это право, а также право REPLICATION_APPLIER для установки gtid_next на значение AUTOMATIC:TAG. Это проверяется при запуске потока репликации.

    Это право также необходимо для установки переменной серверной системы gtid_purged.

    Дополнительную информацию об использовании GTID с метками см. в описании gtid_next, а также Раздел 19.1.4, «Изменение режима GTID на онлайн-серверах».

  • VERSION_TOKEN_ADMIN

    Разрешает выполнение функций Version Tokens. Это право устарело начиная с MySQL 9.2.0 и определяется плагином version_tokens (также устарел); см. Раздел 7.6.6, «Version Tokens».

  • XA_RECOVER_ADMIN

    Разрешает выполнение инструкции XA RECOVER; см. Раздел 15.3.8.1, «SQL-инструкции транзакций XA».

    До MySQL 9.2 любой пользователь мог выполнить инструкцию XA RECOVER для определения значений XID для ожидающих подготовленных транзакций XA, что могло привести к подтверждению или отмене транзакции XA пользователем, отличным от того, кто ее начал. В MySQL 9.2 разрешено выполнять XA RECOVER только пользователям, у которых есть право XA_RECOVER_ADMIN, которое, как ожидается, будет предоставлено только административным пользователям, которые в этом нуждаются. Такая необходимость может возникнуть, например, для администраторов приложения XA, если оно потерпело сбой, и необходимо найти ожидающие транзакции, запущенные приложением, чтобы их можно было отменить. Это требование по правам предотвращает получение пользователями значений XID для ожидающих подготовленных транзакций XA, отличных от их собственных. Это не влияет на нормальное подтверждение или отмену транзакции XA, поскольку пользователь, который ее начал, знает ее XID.

Рекомендации по предоставлению привилегий

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

  • Право FILE может быть злоупотреблено для чтения в таблицу базы данных любых файлов, которые может прочитать сервер MySQL на хосте сервера. Это включает все файлы с общедоступным доступом и файлы в каталоге данных сервера. Затем к таблице можно получить доступ с помощью SELECT для передачи ее содержимого на хост клиента.

  • GRANT OPTION позволяет пользователям предоставлять свои привилегии другим пользователям. Два пользователя с разными привилегиями и правом GRANT OPTION могут объединить привилегии.

  • ALTER может использоваться для обхода системы привилегий путем переименования таблиц.

  • SHUTDOWN может быть использовано для полного отказа в обслуживании других пользователей путем завершения работы сервера.

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

  • SUPER может использоваться для завершения работы других сеансов или изменения работы сервера.

  • Привилегии, предоставленные для самой базы данных mysql, могут использоваться для изменения паролей и другой информации о правах доступа:

    • Пароли хранятся в зашифрованном виде, поэтому злоумышленник не может просто прочитать их, чтобы узнать открытый пароль. Однако пользователь с правом записи в таблицу системы mysql.user столбец authentication_string может изменить пароль учетной записи и затем подключиться к серверу MySQL с использованием этой учетной записи.

    • INSERT или UPDATE, предоставленные для базы данных системы mysql, позволяют пользователю добавлять или изменять существующие привилегии соответственно.

    • DROP для базы данных системы mysql позволяет пользователю удалять таблицы привилегий или даже саму базу данных.

Статические и динамические привилегии

MySQL поддерживает статические и динамические привилегии:

  • Статические привилегии встроенные в сервер. Они всегда доступны для предоставления учетным записям пользователей и не могут быть аннулированы.

  • Динамические привилегии могут быть зарегистрированы и аннулированы во время выполнения. Это влияет на их доступность: динамическая привилегия, которая не была зарегистрирована, не может быть предоставлена.

Например, привилегии SELECT и INSERT являются статическими и всегда доступны, тогда как динамическая привилегия становится доступной только в том случае, если компонент, реализующий ее, был включен.

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

Примечание

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

Компоненты сторонних разработчиков также могут определять динамические привилегии; администратор должен понимать эти привилегии и не устанавливать компоненты, которые могут привести к конфликту или нарушению работы сервера. Например, один компонент конфликтует с другим, если оба определяют привилегию с одинаковым именем. Разработчики компонентов могут снизить вероятность этого, выбрав имена привилегий, имеющие префикс, основанный на имени компонента.

Сервер сохраняет набор зарегистрированных динамических привилегий во внутренней памяти. Аннулирование происходит при выключении сервера.

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

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

INSTALL COMPONENT 'my_component';
UNINSTALL COMPONENT 'my_component';
INSTALL COMPONENT 'my_component';

Первая инструкция INSTALL COMPONENT регистрирует все привилегии, определенные компонентом my_component, но UNINSTALL COMPONENT не аннулирует их. Для второй инструкции INSTALL COMPONENT привилегии компонента, которые она регистрирует, оказываются уже зарегистрированными, но предупреждения или ошибки не возникают.

Динамические привилегии применяются только на глобальном уровне. Сервер сохраняет информацию о текущих назначениях динамических привилегий учетным записям пользователей в таблице системы mysql.global_grants:

  • Сервер автоматически регистрирует привилегии, перечисленные в global_grants, во время запуска сервера (если не задан параметр --skip-grant-tables).

  • Инструкции GRANT и REVOKE изменяют содержимое таблицы global_grants.

  • Назначения динамических привилегий, перечисленные в global_grants, постоянные. Они не удаляются при завершении работы сервера.

Пример: следующая инструкция предоставляет пользователю u1 привилегии, необходимые для управления репликацией (включая Group Replication) на реплике и для изменения системных переменных:

GRANT REPLICATION_SLAVE_ADMIN, GROUP_REPLICATION_ADMIN, BINLOG_ADMIN
ON *.* TO 'u1'@'localhost';

Предоставленные динамические привилегии отображаются в выводе инструкции SHOW GRANTS и в таблице INFORMATION_SCHEMA USER_PRIVILEGES.

Для инструкций GRANT и REVOKE на глобальном уровне любые привилегии, не распознанные как статические, проверяются на соответствие текущему набору зарегистрированных динамических привилегий и предоставляются, если они найдены. В противном случае возникает ошибка, указывающая на неизвестный идентификатор привилегии.

Для инструкций GRANT и REVOKE значение ALL [PRIVILEGES] на глобальном уровне включает все статические глобальные привилегии, а также все текущие зарегистрированные динамические привилегии:

  • GRANT ALL на глобальном уровне предоставляет все статические глобальные привилегии и все текущие зарегистрированные динамические привилегии. Динамическая привилегия, зарегистрированная после выполнения инструкции GRANT, не предоставляется ретроактивно ни одной учетной записи.

  • REVOKE ALL на глобальном уровне отменяет все предоставленные статические глобальные привилегии и все предоставленные динамические привилегии.

Инструкция FLUSH PRIVILEGES считывает таблицу global_grants для назначения динамических привилегий и регистрирует любые не зарегистрированные привилегии, найденные там.

Описание динамических привилегий, предоставляемых MySQL Server и включенных в дистрибутивы MySQL, см. в разделе 8.2.2 «Предоставляемые MySQL привилегии».

Миграция учетных записей с SUPER на динамические привилегии

В MySQL 9.2 многие операции, которые ранее требовали привилегии SUPER, также связаны с динамической привилегией более ограниченного охвата. (Описание этих привилегий см. в разделе 8.2.2 «Предоставляемые MySQL привилегии».) Каждая такая операция может быть разрешена учетной записи путем предоставления соответствующей динамической привилегии вместо SUPER. Это изменение улучшает безопасность, позволяя администраторам баз данных избегать предоставления SUPER и более точно настраивать привилегии пользователей для разрешенных операций. SUPER теперь устарела; ожидается ее удаление в будущих версиях MySQL.

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

  1. Выполните этот запрос, чтобы определить учетные записи, которым предоставлена SUPER:

    SELECT GRANTEE FROM INFORMATION_SCHEMA.USER_PRIVILEGES
WHERE PRIVILEGE_TYPE = 'SUPER';

  2. Для каждой учетной записи, определенной предыдущим запросом, определите операции, для которых ей нужна SUPER. Затем предоставьте соответствующие динамические привилегии и аннулируйте SUPER.

    Например, если 'u1'@'localhost' требует SUPER для очистки двоичного журнала и изменения системных переменных, эти инструкции внесут необходимые изменения в учетную запись:

    GRANT BINLOG_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'u1'@'localhost';
REVOKE SUPER ON *.* FROM 'u1'@'localhost';

    После внесения изменений во все соответствующие учетные записи запрос INFORMATION_SCHEMA в первом шаге должен возвращать пустой результат.

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-9.2-en/privileges-provided.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API