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特权，并且您必须拥有您正在授予的特权。

使用REVOKE语句撤销使用GRANT语句授予的特权。

使用SHOW GRANTS语句确定账户拥有哪些特权。

账户名称

对于GRANT语句，账户名称是指与CREATE USER语句相同的方式中的username参数。有关指定账户名称的详细信息，请参阅CREATE USER页面上的账户名称。

隐式账户创建

GRANT语句还允许您在某些情况下隐式创建账户。

如果该账户尚不存在，则GRANT可以隐式创建它。要使用GRANT隐式创建账户，需要用户具有与使用CREATE USER语句显式创建账户所需的相同特权。

如果设置了NO_AUTO_CREATE_USERSQL_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授予。全局权限包括管理数据库和管理用户帐户的权限，以及所有表、函数和过程的权限。全局权限存储在MariaDB 10.4之前的mysql.user表中，在之后存储在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 权限。您可以使用 GRANT 语句中的 USAGE 权限来更改选项，例如 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

MariaDB 10.5.2 中的新名称为REPLICATION CLIENT，(REPLICATION CLIENT仍作为兼容性别名支持)。允许运行与二进制日志相关的SHOW命令，特别是SHOW BINLOG STATUS和SHOW BINARY LOGS语句。与MariaDB 10.5之前的REPLICATION CLIENT不同，该权限不包括SHOW REPLICA STATUS，并且需要REPLICA MONITOR权限。

BINLOG REPLAY

启用使用BINLOG语句（由mariadb-binlog生成）回放二进制日志，当secure_timestamp设置为replication时执行SET timestamp，并设置通常包括在BINLOG输出中的系统变量的会话值，特别是：

• gtid_domain_id
• gtid_seq_no
• pseudo_thread_id
• server_id

在MariaDB 10.5.2中添加

CONNECTION ADMIN

启用管理连接资源限制选项。这包括忽略由以下选项指定的限制：

• max_connections
• max_user_connections和
• max_password_errors。

以下语句指定在初始化连接时不执行，允许终止其他用户拥有的连接和查询。可以更改以下与连接相关的系统变量：

• connect_timeout
• disconnect_on_expired_password
• extra_max_connections
• init_connect
• max_connections
• max_connect_errors
• max_password_errors
• 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, and
• thread_pool_stall_limit

添加于 MariaDB 10.5.2。

CREATE USER

使用 CREATE USER 语句创建用户，或使用 GRANT 语句隐式创建用户。

FEDERATED ADMIN

执行 CREATE SERVER、ALTER SERVER 和 DROP SERVER 语句。添加于 MariaDB 10.5.2。

FILE

使用类似 LOAD DATA INFILE 或函数 LOAD_FILE() 的语句在服务器上读写文件。还需要创建 CONNECT 外部表。MariaDB 服务器必须具有访问这些文件的权限。

GRANT OPTION

授予全局权限。您只能授予您拥有的权限。

PROCESS

显示有关活动进程的信息，例如通过 SHOW PROCESSLIST 或 mysqladmin 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 权限，并确保没有人可以对任何非临时表进行任何更改。当想要确保副本与主服务器完全相同时，在副本上很有用。

RELOAD

执行 FLUSH 语句或等效的 mariadb-admin/mysqladmin 命令。

REPLICATION CLIENT

执行 SHOW MASTER STATUS 和 SHOW BINARY LOGS 等信息性语句。在 MariaDB 10.5.2 中更名为 BINLOG MONITOR（但仍作为别名支持，以确保兼容性）。在 MariaDB 10.5 之前，SHOW SLAVE STATUS 是 REPLICATION CLIENT 的一部分。

REPLICATION MASTER ADMIN

允许管理主服务器，包括 SHOW REPLICA HOSTS 语句以及设置 gtid_binlog_state、gtid_domain_id、master_verify_checksum 和 server_id 系统变量。添加于 MariaDB 10.5.2。

REPLICA MONITOR

允许执行 SHOW REPLICA STATUS 和 SHOW RELAYLOG EVENTS。自 MariaDB 10.5.9 起。

当用户从旧版主要版本升级到 MariaDB 10.5 次要版本之前的版本时，在某些用户帐户中可能会失去某些功能。例如，在旧版主要版本中拥有 REPLICATION CLIENT 权限的用户帐户可以运行 SHOW REPLICA STATUS，但在升级到 MariaDB 10.5 次要版本之前的版本后，他们不能再运行 SHOW REPLICA STATUS，因为该语句已更改为需要 REPLICATION REPLICA ADMIN 权限。

当用户从旧的主版本升级到 MariaDB 10.5 的次要版本之前的某个版本时，某些用户帐户将失去功能。例如，在旧的主版本中具有 REPLICATION CLIENT 特权的用户帐户可以运行 SHOW REPLICA STATUS，但在升级到 MariaDB 10.5 的次要版本之前的某个版本后，他们将无法再运行 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 及更高版本时，用户将不得不手动修复任何用户帐户特权。

REPLICATION REPLICA

REPLICATION SLAVE 的同义词。从 MariaDB 10.5.1 开始。

REPLICATION SLAVE

主服务器上用于副本服务器的帐户需要此特权。这是为了获得在主服务器上进行的更新。从 MariaDB 10.5.1 开始，REPLICATION REPLICA 是 REPLICATION SLAVE 的别名。

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
• read_binlog_speed_limit
• 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, and
• sync_relay_log_info

添加于 MariaDB 10.5.2。

SET USER

在创建 triggers、views、stored functions 和 stored procedures 时启用设置 DEFINER。从 MariaDB 10.5.2 开始添加。

SHOW DATABASES

使用 SHOW DATABASES 语句列出所有数据库。如果没有 SHOW DATABASES 特权，您仍然可以发出 SHOW DATABASES 语句，但它只会列出包含您有特权的表的数据库。

SHUTDOWN

使用 SHUTDOWN 或 mysqladmin shutdown 命令关闭服务器。

SUPER

执行超级用户语句：CHANGE MASTER TO，KILL（没有此特权的用户只能 KILL 自己的线程），PURGE LOGS，SET global system variables 或 mysqladmin debug 命令。此外，该权限允许用户即使设置了 read_only 启动选项，也可以写入数据，启用或禁用日志记录，在副本上启用或禁用复制，对支持该子句的语句指定 DEFINER，在达到 MAX_CONNECTIONS 后连接。如果已为 init-connect mysqld 选项指定了语句，则当具有 SUPER 特权的用户连接到服务器时，不会执行该命令。

从 MariaDB 10.5.2 开始，SUPER 特权已分成多个较小的特权，以允许更细粒度的特权。

从 MariaDB 10.11.0 开始，已将 READ_ONLY ADMIN 特权从 SUPER 中删除。这样做的好处是可以从所有用户中删除 READ_ONLY ADMIN 特权，并确保没有人可以对任何非临时表进行任何更改。当希望确保副本与主服务器保持相同时，这在副本上很有用。

数据库特权

以下表格列出了可以在数据库级别授予的特权。您还可以在数据库级别授予所有表和函数特权。数据库上的表和函数特权适用于该数据库中的所有表或函数，包括稍后创建的表或函数。

要为数据库设置特权，请使用 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进行用户和组映射。

例如，要授予使用pam身份验证插件进行身份验证的匿名帐户的PROXY权限，您可以执行以下操作：

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权限，并且该权限已定义为WITH GRANT OPTION，则用户帐户只能为特定用户帐户授予PROXY权限。例如，以下示例失败，因为授权者根本没有该特定用户帐户的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权限：

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()  |
+-----------------+-----------------+

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)

由mysql_install_db创建的默认root用户帐户具有此权限。例如：

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更改用户的密码。

此子句支持的唯一authentication plugins是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，则该用户的该资源没有限制。

要为帐户设置资源限制，如果您不想更改该帐户的权限，则可以使用没有意义的USAGE权限发出 GRANT语句。该语句可以按任何顺序命名某些或所有限制类型。

以下是一个设置资源限制的示例：

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

资源是按帐户跟踪的，这意味着按 'user'@'server' 跟踪，而不是按用户名或连接跟踪。

可以使用 FLUSH USER_RESOURCES、FLUSH PRIVILEGES 或 mysqladmin 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 允许您使用传输层安全性（TLS）协议在服务器和客户端之间加密传输数据。TLS 以前称为安全套接字层（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 语句还用于将 角色 的使用授予一个或多个用户或其他角色。为了能够授予角色，执行此操作的授权者必须有权限这样做（请参见 CREATE ROLE 文章中的 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 允许您在不使用 GRANT 的情况下启动 MariaDB。如果您忘记了 root 密码，这很有用。
• CREATE USER
• ALTER USER
• DROP USER
• SET PASSWORD
• SHOW CREATE USER
• mysql.global_priv 表
• mysql.user 表
• 密码验证插件 - 允许设置密码的基本标准
• 认证插件 - 允许使用各种认证方法，并开发新的方法。