GRANT

Синтаксис

GRANT
    priv_type [(column_list)]
      [, priv_type [(column_list)]] ...
    ON [object_type] priv_level
    TO user_specification [ user_options ...]

user_specification:
  username [authentication_option]
  | PUBLIC
authentication_option:
  IDENTIFIED BY 'password' 
  | IDENTIFIED BY PASSWORD 'password_hash'
  | IDENTIFIED {VIA|WITH} authentication_rule [OR authentication_rule  ...]

authentication_rule:
    authentication_plugin
  | authentication_plugin {USING|AS} 'authentication_string'
  | authentication_plugin {USING|AS} PASSWORD('password')

GRANT PROXY ON username
    TO user_specification [, user_specification ...]
    [WITH GRANT OPTION]

GRANT rolename TO grantee [, grantee ...]
    [WITH ADMIN OPTION]

grantee:
    rolename
    username [authentication_option]

user_options:
    [REQUIRE {NONE | tls_option [[AND] tls_option] ...}]
    [WITH with_option [with_option] ...]

object_type:
    TABLE
  | FUNCTION
  | PROCEDURE
  | PACKAGE

priv_level:
    *
  | *.*
  | db_name.*
  | db_name.tbl_name
  | tbl_name
  | db_name.routine_name

with_option:
    GRANT OPTION
  | resource_option

resource_option:
  MAX_QUERIES_PER_HOUR count
  | MAX_UPDATES_PER_HOUR count
  | MAX_CONNECTIONS_PER_HOUR count
  | MAX_USER_CONNECTIONS count
  | MAX_STATEMENT_TIME time

tls_option:
  SSL 
  | X509
  | CIPHER 'cipher'
  | ISSUER 'issuer'
  | SUBJECT 'subject'

Описание

Оператор GRANT позволяет предоставить привилегии или роли учётным записям. Для использования GRANT, необходимо иметь привилегию GRANT OPTION, а также привилегии, которые вы предоставляете.

Для отзыва привилегий, предоставленных оператором GRANT, используйте оператор REVOKE.

Для определения привилегий, имеющихся у учётной записи, используйте оператор SHOW GRANTS.

Имена учётных записей

Для операторов GRANT, имена учётных записей указываются как аргумент username таким же образом, как и для операторов CREATE USER. Подробности о том, как указываются имена учётных записей, см. на странице имен учётных записей на странице CREATE USER.

Неявное создание учётных записей

Оператор GRANT также позволяет в некоторых случаях неявно создавать учётные записи.

Если учётной записи ещё нет, то GRANT может неявно её создать. Для неявного создания учётной записи с помощью GRANT, пользователю необходимы те же привилегии, которые потребовались бы для явного создания учётной записи с помощью оператора CREATE USER.

Если параметр NO_AUTO_CREATE_USER SQL_MODE установлен, то учётные записи могут быть созданы только при указании информации для аутентификации или с помощью оператора CREATE USER. Если информация для аутентификации не указана, GRANT выдаст ошибку, если указанной учётной записи не существует, например:

show variables like '%sql_mode%' ;
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| sql_mode      | NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+--------------------------------------------+

GRANT USAGE ON *.* TO 'user123'@'%' IDENTIFIED BY '';
ERROR 1133 (28000): Can't find any matching row in the user table

GRANT USAGE ON *.* TO 'user123'@'%' 
  IDENTIFIED VIA PAM using 'mariadb' require ssl ;
Query OK, 0 rows affected (0.00 sec)
 
select host, user from mysql.user where user='user123' ;

+------+----------+
| host | user     |
+------+----------+
| %    | user123 |
+------+----------+

Уровни привилегий

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

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

• Глобальные привилегии priv_type предоставляются с использованием *.* для priv_level. Глобальные привилегии включают привилегии для администрирования базы данных и управления учётными записями, а также привилегии для всех таблиц, функций и процедур. Глобальные привилегии хранятся в таблице mysql.user до версии MariaDB 10.4, и в таблице mysql.global_priv после.
• Привилегии базы данных priv_type предоставляются с использованием db_name.* для priv_level или просто * для использования по умолчанию базы данных. Привилегии базы данных включают привилегии для создания таблиц и функций, а также привилегии для всех таблиц, функций и процедур в базе данных. Привилегии базы данных хранятся в таблице mysql.db.
• Привилегии таблицы priv_type предоставляются с использованием db_name.tbl_name для priv_level или просто tbl_name для указания таблицы в базе данных по умолчанию. Ключевое слово TABLE необязательно. Привилегии таблицы включают возможность выбора и изменения данных в таблице. Некоторые привилегии таблиц могут предоставляться для отдельных столбцов.
• Привилегии столбцов priv_type предоставляются путем указания таблицы для priv_level и предоставления списка столбцов после типа привилегии. Они позволяют контролировать, какие именно столбцы в таблице пользователи могут выбирать и изменять.
• Привилегии функций priv_type предоставляются с использованием FUNCTION db_name.routine_name для priv_level или просто FUNCTION routine_name для указания функции в базе данных по умолчанию.
• Привилегии процедур priv_type предоставляются с использованием PROCEDURE db_name.routine_name для priv_level или просто PROCEDURE routine_name для указания процедуры в базе данных по умолчанию.

Привилегия USAGE

Привилегия USAGE не предоставляет реальных привилегий. Оператор SHOW GRANTS отобразит глобальную привилегию USAGE для недавно созданного пользователя. Вы можете использовать USAGE с оператором GRANT для изменения таких параметров, как GRANT OPTION и MAX_USER_CONNECTIONS, без изменения каких-либо привилегий учётной записи.

Привилегия ALL PRIVILEGES

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

Использование ALL PRIVILEGES не предоставляет специальной привилегии GRANT OPTION.

Вы можете использовать ALL вместо ALL PRIVILEGES.

Привилегия GRANT OPTION

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

Привилегия GRANT OPTION не может быть установлена для отдельных столбцов. Если вы используете WITH GRANT OPTION при указании привилегий столбцов, привилегия GRANT OPTION будет предоставлена для всей таблицы.

Использование предложения WITH GRANT OPTION эквивалентно перечислению GRANT OPTION как привилегии.

Глобальные привилегии

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

Для установки глобальной привилегии используйте *.* для priv_level.

BINLOG ADMIN

Включает администрирование бинарного журнала, включая оператор PURGE BINARY LOGS и установку системных переменных:

• binlog_annotate_row_events
• binlog_cache_size
• binlog_commit_wait_count
• binlog_commit_wait_usec
• binlog_direct_non_transactional_updates
• binlog_expire_logs_seconds
• binlog_file_cache_size
• binlog_format
• binlog_row_image
• binlog_row_metadata
• binlog_stmt_cache_size
• expire_logs_days
• log_bin_compress
• log_bin_compress_min_len
• log_bin_trust_function_creators
• max_binlog_cache_size
• max_binlog_size
• max_binlog_stmt_cache_size
• sql_log_bin и
• sync_binlog.

Добавлена в MariaDB 10.5.2.

BINLOG MONITOR

Новое название для REPLICATION CLIENT с версии MariaDB 10.5.2, (REPLICATION CLIENT по-прежнему поддерживается как псевдоним для совместимости). Разрешает выполнение команд SHOW, связанных с бинарным журналом, в частности операторов SHOW BINLOG STATUS и SHOW BINARY LOGS. В отличие от REPLICATION CLIENT до MariaDB 10.5, SHOW REPLICA STATUS не включен в эту привилегию, и требуется привилегия REPLICA MONITOR.

BINLOG REPLAY

Разрешает воспроизведение бинарного журнала с оператором BINLOG (сгенерированного mariadb-binlog), выполнение SET timestamp при установке secure_timestamp на replication, и установку сессионных значений системных переменных, обычно включенных в выходные данные BINLOG, в частности:

• gtid_domain_id
• gtid_seq_no
• pseudo_thread_id
• server_id.

Добавлена в MariaDB 10.5.2

CONNECTION ADMIN

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

• макс_соединений
• макс_соединений_пользователя и
• макс_ошибок_пароля.

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

• connect_timeout
• disconnect_on_expired_password
• extra_max_connections
• init_connect
• макс_соединений
• макс_ошибок_соединения
• макс_ошибок_пароля
• proxy_protocol_networks
• secure_auth
• slow_launch_time
• thread_pool_exact_stats
• thread_pool_dedicated_listener
• thread_pool_idle_timeout
• thread_pool_max_threads
• thread_pool_min_threads
• thread_pool_oversubscribe
• thread_pool_prio_kickup_timer
• thread_pool_priority
• thread_pool_size, и
• thread_pool_stall_limit.

Добавлена в MariaDB 10.5.2.

СОЗДАНИЕ ПОЛЬЗОВАТЕЛЯ

Создайте пользователя с помощью оператора CREATE USER или неявно создайте пользователя с помощью оператора GRANT.

FEDERATED ADMIN

Выполните операторы CREATE SERVER, ALTER SERVER и DROP SERVER. Добавлена в MariaDB 10.5.2.

ФАЙЛ

Чтение и запись файлов на сервере с помощью операторов, таких как LOAD DATA INFILE, или функций, таких как LOAD_FILE(). Также необходимо для создания внешних таблиц CONNECT. Сервер MariaDB должен иметь разрешения на доступ к этим файлам.

РАЗРЕШЕНИЕ НА НАДЕЛЕНИЕ ПРАВАМИ

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

ПРОЦЕСС

Отображение информации об активных процессах, например, с помощью SHOW PROCESSLIST или mariadb-admin processlist. Если у вас есть привилегия PROCESS, вы можете увидеть все потоки. В противном случае вы можете увидеть только свои собственные потоки (то есть потоки, связанные с учётной записью MariaDB, которую вы используете).

READ_ONLY ADMIN

Пользователь может установить системную переменную read_only и разрешает пользователю выполнять операции записи, даже когда активен параметр read_only. Добавлена в MariaDB 10.5.2.

С MariaDB 10.11.0 привилегия READ_ONLY ADMIN была удалена из SUPER. Это позволяет удалить привилегию READ_ONLY ADMIN у всех пользователей и гарантировать, что никто не сможет внести изменения в таблицы, которые не являются временными. Это полезно на репликах, когда нужно убедиться, что реплика идентична первичному серверу.

ПЕРЕЗАГРУЗКА

Выполнение операторов FLUSH или эквивалентных команд mariadb-admin.

КЛИЕНТ РЕПЛИКАЦИИ

Выполнение информативных операторов SHOW MASTER STATUS и SHOW BINARY LOGS. Переименовано в BINLOG MONITOR в MariaDB 10.5.2 (но по-прежнему поддерживается как псевдоним по соображениям совместимости). SHOW SLAVE STATUS входил в КЛИЕНТ РЕПЛИКАЦИИ до MariaDB 10.5.

ADMIN РЕПЛИКАЦИИ МАСТЕР

Разрешает администрирование первичных серверов, включая оператор SHOW REPLICA HOSTS, и установку системных переменных gtid_binlog_state, gtid_domain_id, master_verify_checksum и server_id. Добавлена в MariaDB 10.5.2.

МОНИТОР РЕПЛИКИ

Разрешает использование SHOW REPLICA STATUS и SHOW RELAYLOG EVENTS. С MariaDB 10.5.9.

При обновлении базы данных со старшей версии до MariaDB 10.5 младшей версии до MariaDB 10.5.9, определённые учётные записи пользователей могли потерять возможности. Например, учётная запись пользователя, имеющая привилегию REPLICATION CLIENT в более ранних версиях, могла выполнять SHOW REPLICA STATUS, но после обновления до MariaDB 10.5 младшей версии до MariaDB 10.5.9 они больше не могли выполнять SHOW REPLICA STATUS, так как этот оператор требует привилегии REPLICATION REPLICA ADMIN.

Эта проблема исправлена в MariaDB 10.5.9 с новой привилегией, которая теперь даёт пользователю возможность выполнять SHOW [ALL] (SLAVE | REPLICA) STATUS.

При обновлении базы данных со старой версии до MariaDB Server 10.5.9 или более поздней версии, любые учётные записи пользователей с привилегиями REPLICATION CLIENT или REPLICATION SLAVE автоматически получат новую привилегию REPLICA MONITOR. Исправление привилегий происходит при запуске сервера, а не при выполнении mariadb-upgrade.

Однако при обновлении базы данных со ранней версии 10.5 до 10.5.9 и выше, пользователю придётся вручную исправить привилегии учётных записей пользователей.

РЕПЛИКАЦИЯ РЕПЛИКА

Синоним для РЕПЛИКАЦИЯ СЛЕЙВ. С MariaDB 10.5.1.

РЕПЛИКАЦИЯ СЛЕЙВ

Учётные записи, используемые реплицирующими серверами на первичном, нуждаются в этой привилегии. Это необходимо, чтобы получить обновления, внесенные на мастер. С MariaDB 10.5.1, РЕПЛИКАЦИЯ РЕПЛИКА — это псевдоним для REPLICATION SLAVE.

ADMIN РЕПЛИКАЦИИ СЛЕЙВ

Разрешает администрирование серверов реплик, включая операторы START REPLICA/SLAVE, STOP REPLICA/SLAVE, CHANGE MASTER, SHOW REPLICA/SLAVE STATUS, SHOW RELAYLOG EVENTS, переигрывание бинарного журнала с оператором BINLOG (сгенерированный mariadb-binlog), и установку системных переменных:

• gtid_cleanup_batch_size
• gtid_ignore_duplicates
• gtid_pos_auto_engines
• gtid_slave_pos
• gtid_strict_mode
• init_slave
• предельный_скорость_чтения_binlog
• relay_log_purge
• relay_log_recovery
• replicate_do_db
• replicate_do_table
• replicate_events_marked_for_skip
• replicate_ignore_db
• replicate_ignore_table
• replicate_wild_do_table
• replicate_wild_ignore_table
• slave_compressed_protocol
• slave_ddl_exec_mode
• slave_domain_parallel_threads
• slave_exec_mode
• slave_max_allowed_packet
• slave_net_timeout
• slave_parallel_max_queued
• slave_parallel_mode
• slave_parallel_threads
• slave_parallel_workers
• slave_run_triggers_for_rbr
• slave_sql_verify_checksum
• slave_transaction_retry_interval
• slave_type_conversions
• sync_master_info
• sync_relay_log, и
• sync_relay_log_info.

Добавлен в MariaDB 10.5.2.

УСТАНОВКА ПОЛЬЗОВАТЕЛЯ

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

ПОКАЗАТЬ БАЗЫ ДАННЫХ

Список всех баз данных с помощью оператора SHOW DATABASES. Без привилегии SHOW DATABASES, вы всё равно можете использовать оператор SHOW DATABASES, но он будет отображать только базы данных, содержащие таблицы, на которых у вас есть привилегии.

ВЫКЛЮЧЕНИЕ

Выключение сервера с помощью SHUTDOWN или команды mariadb-admin shutdown.

SUPER

Выполнение команд суперпользователя: CHANGE MASTER TO, KILL (пользователи, не имеющие этого привилегия, могут только KILL свои собственные потоки), PURGE LOGS, SET глобальные системные переменные или команда mariadb-admin debug. Кроме того, эта разрешение позволяет пользователю записывать данные, даже если установлен параметр запуска read_only, включить или отключить ведение журнала, включить или отключить репликацию на реплике, указать DEFINER для инструкций, которые поддерживают этот клаузу, подключиться, достигнув MAX_CONNECTIONS. Если для параметра init-connect mysqld была указана команда, она не будет выполнена при подключении пользователя с привилегиями SUPER к серверу.

Привилегия SUPER была разделена на несколько меньших привилегий начиная с MariaDB 10.5.2, чтобы разрешить более тонкую настройку привилегий (MDEV-21743). Привилегии:

• УСТАНОВКА ПОЛЬЗОВАТЕЛЯ
• FEDERATED ADMIN
• CONNECTION ADMIN
• УПРАВЛЕНИЕ РЕПЛИКАМИ
• УПРАВЛЕНИЕ BINLOG
• BINLOG REPLAY
• MONITOR РЕПЛИКИ
• BINLOG MONITOR
• УПРАВЛЕНИЕ MASTER РЕПЛИКАЦИИ
• READ_ONLY ADMIN

Однако, меньшие привилегии всё ещё являются частью разрешения SUPER в MariaDB 10.5.2. Начиная с MariaDB 11.0.1, эти разрешения больше не являются частью SUPER и должны быть предоставлены отдельно (MDEV-29668).

Начиная с MariaDB 10.11.0, привилегия READ_ONLY ADMIN была удалена из SUPER. Преимущество этого заключается в том, что можно удалить привилегию READ_ONLY ADMIN у всех пользователей и гарантировать, что никто не сможет внести изменения в любые таблицы, не являющиеся временными. Это полезно для реплик, когда необходимо гарантировать, что реплика идентична первичной (MDEV-29596).

Привилегии баз данных

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

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

Привилегии таблиц

Привилегии на столбцы

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

GRANT SELECT (name, position) on Employee to 'jeffrey'@'localhost';

Привилегии на функции

Привилегии на процедуры

GRANT EXECUTE ON PROCEDURE mysql.create_db TO maintainer;

Привилегии прокси

Привилегия PROXY позволяет одному пользователю выступать в роли прокси для другого пользователя, что означает, что его привилегии изменяются на привилегии прокси-пользователя, и функция CURRENT_USER() возвращает имя пользователя-прокси.

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

Плагин аутентификации pam — единственный плагин, включенный в MariaDB, который в настоящее время поддерживает прокси-пользователей. Привилегия PROXY обычно используется с плагином аутентификации pam для включения сопоставления пользователей и групп с PAM.

Например, чтобы предоставить привилегию PROXY анонимной учётной записи, которая аутентифицируется с помощью плагина аутентификации pam, можно выполнить следующее:

CREATE USER 'dba'@'%' IDENTIFIED BY 'strongpassword';
GRANT ALL PRIVILEGES ON *.* TO 'dba'@'%' ;

CREATE USER ''@'%' IDENTIFIED VIA pam USING 'mariadb';
GRANT PROXY ON 'dba'@'%' TO ''@'%';

Учётная запись пользователя может предоставить привилегию PROXY для конкретной учётной записи пользователя только в том случае, если у лица, предоставляющего привилегию, также есть привилегия PROXY для этой конкретной учётной записи пользователя и если эта привилегия определена WITH GRANT OPTION. Например, следующий пример не удаётся, потому что у лица, предоставляющего привилегию, вообще нет привилегии PROXY для этой конкретной учётной записи пользователя:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
+-----------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'dba'@'localhost' TO 'bob'@'localhost';
ERROR 1698 (28000): Access denied for user 'alice'@'localhost'

И следующий пример не удаётся, потому что у лица, предоставляющего привилегию, есть привилегия PROXY для этой конкретной учётной записи пользователя, но она не определена WITH GRANT OPTION:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
| GRANT PROXY ON 'dba'@'localhost' TO 'alice'@'localhost'                                                               |
+-----------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'dba'@'localhost' TO 'bob'@'localhost';
ERROR 1698 (28000): Access denied for user 'alice'@'localhost'

Но следующий пример удаётся, потому что у лица, предоставляющего привилегию, есть привилегия PROXY для этой конкретной учётной записи пользователя, и она определена WITH GRANT OPTION:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                                              |
+-----------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' WITH GRANT OPTION |
| GRANT PROXY ON 'dba'@'localhost' TO 'alice'@'localhost' WITH GRANT OPTION                                                               |
+-----------------------------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'dba'@'localhost' TO 'bob'@'localhost';

Учётная запись пользователя может предоставить привилегию PROXY для любой другой учётной записи пользователя, если у лица, предоставляющего привилегию, есть привилегия PROXY для анонимной учётной записи ''@'%', как в этом примере:

GRANT PROXY ON ''@'%' TO 'dba'@'localhost' WITH GRANT OPTION;

Например, следующий пример удаётся, потому что пользователь может предоставить привилегию PROXY для любой другой учётной записи пользователя:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                                              |
+-----------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' WITH GRANT OPTION |
| GRANT PROXY ON ''@'%' TO 'alice'@'localhost' WITH GRANT OPTION                                                                          |
+-----------------------------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'app1_dba'@'localhost' TO 'bob'@'localhost';
Query OK, 0 rows affected (0.004 sec)

GRANT PROXY ON 'app2_dba'@'localhost' TO 'carol'@'localhost';
Query OK, 0 rows affected (0.004 sec)

По умолчанию учётные записи пользователей root созданные командой mariadb-install-db, имеют эту привилегию. Например:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
GRANT PROXY ON ''@'%' TO 'root'@'localhost' WITH GRANT OPTION;

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

Параметры аутентификации

Параметры аутентификации для оператора GRANT такие же, как и для оператора CREATE USER.

IDENTIFIED BY 'password'

Дополнительная IDENTIFIED BY определяет пользователя с паролем. Пароль должен быть указан в виде обычного текста. Он будет захеширован функцией PASSWORD перед сохранением.

Например, если наш пароль mariadb, то мы можем создать пользователя:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED BY 'mariadb';

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

Если учетная запись пользователя уже существует и вы используете IDENTIFIED BY , то пароль пользователя будет изменён. У вас должны быть необходимые привилегии для оператора SET PASSWORD, чтобы изменить пароль пользователя с помощью GRANT.

Поддерживаются только плагины аутентификации mysql_native_password и mysql_old_password.

IDENTIFIED BY PASSWORD 'password_hash'

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

Например, если наш пароль mariadb, то мы можем найти хэш:

SELECT PASSWORD('mariadb');
+-------------------------------------------+
| PASSWORD('mariadb')                       |
+-------------------------------------------+
| *54958E764CE10E50764C2EECBB71D01F08549980 |
+-------------------------------------------+
1 row in set (0.00 sec)

А затем мы можем создать пользователя с этим хэшем:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED BY 
  PASSWORD '*54958E764CE10E50764C2EECBB71D01F08549980';

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

Если учетная запись пользователя уже существует и вы используете IDENTIFIED BY , то пароль пользователя будет изменён. У вас должны быть необходимые привилегии для оператора SET PASSWORD, чтобы изменить пароль пользователя с помощью GRANT.

Поддерживаются только плагины аутентификации mysql_native_password и mysql_old_password.

IDENTIFIED {VIA|WITH} authentication_plugin

Дополнительная IDENTIFIED VIA authentication_plugin позволяет указать, что учетная запись должна аутентифицироваться с помощью конкретного плагина аутентификации. Имя плагина должно соответствовать активному плагину аутентификации, как показано в SHOW PLUGINS. Если его нет в этом выводе, то его необходимо установить с помощью INSTALL PLUGIN или INSTALL SONAME.

Например, это можно использовать с плагином аутентификации PAM:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED VIA pam;

Некоторые плагины аутентификации позволяют указывать дополнительные аргументы после ключевого слова USING или AS. Например, плагин аутентификации PAM принимает имя сервиса:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED VIA pam USING 'mariadb';

Точное значение дополнительных аргументов зависит от конкретного плагина аутентификации.

CREATE USER safe@'%' IDENTIFIED VIA ed25519 
  USING PASSWORD('secret');

CREATE USER safe@'%' IDENTIFIED VIA ed25519 
  USING PASSWORD('secret') OR unix_socket;

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

Опции ограничения ресурсов

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

Если любое из этих ограничений установлено в 0, то для этого ресурса для данного пользователя ограничений нет.

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

Вот пример установки ограничений ресурсов:

GRANT USAGE ON *.* TO 'someone'@'localhost' WITH
    MAX_USER_CONNECTIONS 0
    MAX_QUERIES_PER_HOUR 200;

Ресурсы отслеживаются для каждой учетной записи, что означает 'user'@'server', а не для имени пользователя или подключения.

Подсчёт можно сбросить для всех пользователей с помощью FLUSH USER_RESOURCES, FLUSH PRIVILEGES или mariadb-admin reload.

Пользователи с привилегией CONNECTION ADMIN (в MariaDB 10.5.2 и более поздних версиях) или привилегией SUPER не ограничены max_user_connections, max_connections, или max_password_errors.

Ограничения ресурсов для каждой учетной записи хранятся в таблице user базы данных mysql. Столбцы, используемые для ограничения ресурсов, называются max_questions, max_updates, max_connections (для MAX_CONNECTIONS_PER_HOUR) и max_user_connections (для MAX_USER_CONNECTIONS).

Опции TLS

По умолчанию MariaDB передает данные между сервером и клиентами без шифрования. Это обычно приемлемо, когда сервер и клиент работают на одном хосте или в сетях, где безопасность гарантируется другими средствами. Однако в случаях, когда сервер и клиент находятся в разных сетях или в сети с высоким риском, отсутствие шифрования создаёт проблемы безопасности, так как злоумышленник потенциально может перехватывать трафик во время передачи между ними.

Для решения этой проблемы MariaDB позволяет шифровать данные во время передачи между сервером и клиентами с помощью протокола Transport Layer Security (TLS). TLS ранее был известен как Secure Socket Layer (SSL), но строго говоря, SSL является предшественником TLS, и сейчас считается небезопасным. В документации часто используется термин SSL, а по соображениям совместимости переменные системы и состояния сервера, связанные с TLS, по-прежнему используют префикс ssl_, но в MariaDB поддерживаются только его более безопасные преемники.

См. Обзор безопасных соединений для получения дополнительной информации о том, поддерживает ли ваш сервер MariaDB TLS.

Вы можете установить определенные ограничения TLS для конкретных учетных записей пользователей. Например, вы можете использовать это с учетными записями пользователей, которым требуется доступ к конфиденциальным данным при передаче их через сети, которыми вы не управляете. Эти ограничения можно включить для учетной записи пользователя с помощью операторов CREATE USER, ALTER USER или GRANT. Доступны следующие параметры:

Ключевое слово REQUIRE должно использоваться только один раз для всех указанных параметров, а ключевое слово AND может использоваться для разделения отдельных параметров, но это не обязательно.

Например, вы можете создать учетную запись пользователя, которая требует этих параметров TLS, следующим образом:

GRANT USAGE ON *.* TO 'alice'@'%'
  REQUIRE SUBJECT '/CN=alice/O=My Dom, Inc./C=US/ST=Oregon/L=Portland'
  AND ISSUER '/C=FI/ST=Somewhere/L=City/ O=Some Company/CN=Peter Parker/emailAddress=p.parker@marvel.com'
  AND CIPHER 'SHA-DES-CBC3-EDH-RSA';

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

См. Защита подключений для клиента и сервера для получения информации о том, как включить TLS на клиенте и сервере.

Роли

Синтаксис

GRANT role TO grantee [, grantee ... ]
[ WITH ADMIN OPTION ]

grantee:
    rolename
    username [authentication_option]

Оператор GRANT также используется для предоставления права на использование роли одному или нескольким пользователям или другим ролям. Для того, чтобы предоставить роль, у предоставляющего её пользователя должны быть соответствующие права (см. WITH ADMIN в статье СОЗДАНИЕ РОЛИ).

Указание WITH ADMIN OPTION позволяет обладателю роли, в свою очередь, предоставить роль другому.

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

GRANT journalist TO hulda;

GRANT journalist TO berengar WITH ADMIN OPTION;

Если пользователю предоставлена роль, он не получает автоматически все разрешения, связанные с этой ролью. Эти разрешения используются только тогда, когда пользователь активирует роль с помощью оператора SET ROLE.

TO PUBLIC

GRANT <privilege> ON <database>.<object> TO PUBLIC;
REVOKE <privilege> ON <database>.<object> FROM PUBLIC;

Примеры предоставления прав

Предоставление привилегий, похожих на root

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

CREATE USER 'alexander'@'localhost';
GRANT ALL PRIVILEGES ON  *.* to 'alexander'@'localhost' WITH GRANT OPTION;

См. также

• Устранение проблем с подключением
• --skip-grant-tables позволяет запустить MariaDB без GRANT. Это полезно, если вы потеряли пароль root.
• CREATE USER
• ALTER USER
• DROP USER
• SET PASSWORD
• SHOW CREATE USER
• Таблица mysql.global_priv
• Таблица mysql.user
• Плагины проверки паролей - позволяют устанавливать основные критерии для паролей
• Плагины аутентификации - позволяют использовать различные методы аутентификации и разрабатывать новые.