Spec-Zone.ru › MySQL 8.4

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 Администрирование сервера
ENCRYPTION_KEY_ADMIN Администрирование сервера
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 команды
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.20.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

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

  • INSERT

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

  • LOCK TABLES

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

  • PROCESS

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

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

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

    Примечание

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

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

  • PROXY

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

  • REFERENCES

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

  • RELOAD

    Привилегия 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.

  • REPLICATION CLIENT

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

  • REPLICATION SLAVE

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

  • SELECT

    Разрешает выбор строк из таблиц в базе данных. Инструкции 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.

    • Позволяет учетной записи запускать и останавливать репликацию, включая групповую репликацию.

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

    • Позволяет использовать инструкции 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_TOKEN_ADMIN.

    • Позволяет предоставлять и отзывать роли, использовать предложение 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.7, «Бинарное журналирование хранимых программ».

  • 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 8.4 из более ранней версии.

  • 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-сервера требуется 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), без этой привилегии член, переведённый в автономный режим, исключается из группы.

  • ENCRYPTION_KEY_ADMIN

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

  • 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.

  • 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.

  • 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

    Позволяет владельцу просматривать значения конфиденциальных системных переменных в таблицах схемы производительности 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.6, «Управление доступом к хранимым объектам».

  • SHOW_ROUTINE

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

    • Содержимое таблицы схемы Информации 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, «Плагин переписателя запросов»).

    Эта привилегия должна предоставляться пользователям, которые выдают административные или управляющие команды, которые не должны быть переписаны, а также учетным записям 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, “Оператор SET TRANSACTION”).

  • 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; см. Раздел 7.6.6, “Маркеры версии”.

  • XA_RECOVER_ADMIN

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

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

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

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

  • 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 и включенных в дистрибутивы MySQL, см. в Разделе 8.2.2, «Предоставляемые MySQL привилегии».

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

В MySQL 8.4 многие операции, которые ранее требовали привилегии 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-8.4-en/privileges-provided.html

Spec-Zone.ru

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