授予 MySQL 帐户的权限决定了该帐户可以执行哪些操作。MySQL 权限在适用的上下文中和不同的操作级别上有所不同。
管理权限允许用户管理 MySQL 服务器的操作。这些权限是全局的,因为它们不是特定于特定数据库的。
数据库权限适用于数据库及其内部的所有对象。这些权限可以针对特定数据库授予,也可以全局授予,以便它们适用于所有数据库。
数据库对象(如表、索引、视图和存储例程)的权限可以针对数据库中的特定对象授予,针对数据库中给定类型的所有对象授予(例如,数据库中的所有表),或者全局针对所有数据库中给定类型的对象授予。
权限在是否为静态(内置于服务器)或动态(在运行时定义)方面也有所不同。权限是静态的还是动态的会影响其对用户帐户和角色的可用性。有关静态权限和动态权限之间差异的信息,请参见 静态与动态权限。)
有关帐户权限的信息存储在 mysql
系统数据库中的授权表中。有关这些表结构和内容的描述,请参见 第 8.2.3 节,“授权表”。MySQL 服务器在启动时将授权表的内容读入内存,并在 第 8.2.13 节,“权限更改生效时间” 中指示的情况下重新加载它们。服务器根据授权表的内存副本做出访问控制决策。
某些 MySQL 版本对授权表进行了更改,以添加新的权限或功能。为了确保您可以利用任何新功能,在升级 MySQL 时将授权表更新到当前结构。请参见 第 3 章,升级 MySQL。
以下部分总结了可用的权限,提供了对每个权限的更详细描述,并提供了使用指南。
下表显示了 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_priv |
表 |
插入 |
Insert_priv |
表或列 |
锁定表 |
Lock_tables_priv |
数据库 |
进程 |
Process_priv |
服务器管理 |
代理 |
见 proxies_priv 表 |
服务器管理 |
引用 |
References_priv |
数据库或表 |
重新加载 |
Reload_priv |
服务器管理 |
复制客户端 |
Repl_client_priv |
服务器管理 |
复制从属服务器 |
Repl_slave_priv |
服务器管理 |
选择 |
Select_priv |
表或列 |
显示数据库 |
Show_db_priv |
服务器管理 |
显示视图 |
Show_view_priv |
视图 |
关闭 |
Shutdown_priv |
服务器管理 |
超级 |
Super_priv |
服务器管理 |
触发器 |
Trigger_priv |
表 |
更新 |
Update_priv |
表或列 |
使用 |
“无权限”的同义词 | 服务器管理 |
下表显示了在 GRANT
和 REVOKE
语句中使用的动态权限名称,以及该权限适用的上下文。
表 8.3 GRANT 和 REVOKE 允许的动态权限
静态权限内置于服务器,与动态权限形成对比,动态权限是在运行时定义的。以下列表描述了 MySQL 中可用的每个静态权限。
某些 SQL 语句可能具有比这里指示的更具体的权限要求。如果是这样,则所讨论的语句的描述将提供详细信息。
这些权限说明符是 “在给定权限级别可用的所有权限” 的简写(
GRANT OPTION
除外)。例如,在全局或表级别授予ALL
将分别授予所有全局权限或所有表级权限。启用使用
ALTER TABLE
语句更改表的结构。ALTER TABLE
还需要CREATE
和INSERT
权限。重命名表需要ALTER
和DROP
在旧表上,CREATE
和INSERT
在新表上。启用使用更改或删除存储例程(存储过程和函数)的语句。对于属于授予权限范围内的例程,以及对于用户不是例程
DEFINER
中命名为用户的例程,还启用对例程定义以外的例程属性的访问。启用使用创建新数据库和表的语句。
启用使用
CREATE ROLE
语句。(CREATE USER
权限也启用使用CREATE ROLE
语句。)见 第 8.2.10 节,“使用角色”。CREATE ROLE
和DROP ROLE
权限不如CREATE USER
强大,因为它们只能用于创建和删除帐户。它们不能像CREATE USER
一样修改帐户属性或重命名帐户。见 用户和角色可互换性。启用使用创建存储例程(存储过程和函数)的语句。对于属于授予权限范围内的例程,以及对于用户不是例程
DEFINER
中命名为用户的例程,还启用对例程定义以外的例程属性的访问。启用使用创建、更改或删除表空间和日志文件组的语句。
启用使用
CREATE TEMPORARY TABLE
语句创建临时表。在会话创建临时表后,服务器不会对该表执行任何进一步的权限检查。创建会话可以在该表上执行任何操作,例如
DROP TABLE
、INSERT
、UPDATE
或SELECT
。有关更多信息,见 第 15.1.20.2 节,“CREATE TEMPORARY TABLE 语句”。启用使用
ALTER USER
、CREATE ROLE
、CREATE USER
、DROP ROLE
、DROP USER
、RENAME USER
和REVOKE ALL PRIVILEGES
语句。启用使用
CREATE VIEW
语句。启用从数据库中的表中删除行。
启用使用删除(移除)现有数据库、表和视图的语句。
DROP
权限是使用ALTER TABLE ... DROP PARTITION
语句在分区表上所需的。DROP
权限也是TRUNCATE TABLE
所需的。启用使用
DROP ROLE
语句。(CREATE USER
权限也启用使用DROP ROLE
语句。)见 第 8.2.10 节,“使用角色”。CREATE ROLE
和DROP ROLE
权限不如CREATE USER
强大,因为它们只能用于创建和删除帐户。它们不能像CREATE USER
一样修改帐户属性或重命名帐户。见 用户和角色可互换性。启用使用创建、更改、删除或显示事件调度程序事件的语句。
启用使用执行存储例程(存储过程和函数)的语句。对于属于授予权限范围内的例程,以及对于用户不是例程
DEFINER
中命名为用户的例程,还启用对例程定义以外的例程属性的访问。影响以下操作和服务器行为
启用使用
LOAD DATA
和SELECT ... INTO OUTFILE
语句以及LOAD_FILE()
函数在服务器主机上读取和写入文件。具有FILE
权限的用户可以读取服务器主机上的任何文件,这些文件要么是世界可读的,要么是 MySQL 服务器可读的。(这意味着用户可以读取任何数据库目录中的任何文件,因为服务器可以访问那些目录中的任何文件。)启用在 MySQL 服务器具有写入访问权限的任何目录中创建新文件。这包括包含实现权限表的文件的服务器数据目录。
启用使用
DATA DIRECTORY
或INDEX DIRECTORY
表选项用于CREATE TABLE
语句。
作为安全措施,服务器不会覆盖现有文件。
要限制文件读取和写入的位置,请将
secure_file_priv
系统变量设置为特定目录。见 第 7.1.8 节,“服务器系统变量”。启用你向其他用户授予或撤销你拥有的权限。
启用用于创建或删除(移除)索引的语句。
INDEX
应用于现有表。如果您对某个表拥有CREATE
权限,则可以在CREATE TABLE
语句中包含索引定义。启用将行插入数据库中的表。
INSERT
对于ANALYZE TABLE
、OPTIMIZE TABLE
和REPAIR TABLE
表维护语句也是必需的。启用使用显式
LOCK TABLES
语句锁定您拥有SELECT
权限的表。这包括写入锁的使用,它会阻止其他会话读取锁定的表。PROCESS
权限控制对服务器中执行的线程信息的访问(即,对会话正在执行的语句的信息)。使用SHOW PROCESSLIST
语句、 mysqladmin processlist 命令、Information SchemaPROCESSLIST
表和 Performance Schemaprocesslist
表访问的线程信息如下所示注意Performance Schema
threads
表也提供线程信息,但表访问使用不同的权限模型。请参阅 第 29.12.22.8 节“threads 表”。PROCESS
权限还启用使用SHOW ENGINE
语句、访问INFORMATION_SCHEMA
InnoDB
表(名称以INNODB_
开头的表)以及访问INFORMATION_SCHEMA
FILES
表。使一个用户能够模拟或成为另一个用户。请参阅 第 8.2.19 节“代理用户”。
创建外键约束需要对父表拥有
REFERENCES
权限。RELOAD
启用以下操作使用
FLUSH
语句。使用 mysqladmin 等效于
FLUSH
操作的命令:flush-hosts
、flush-logs
、flush-privileges
、flush-status
、flush-tables
、refresh
和reload
。reload
命令告诉服务器将授权表重新加载到内存中。flush-privileges
是reload
的同义词。refresh
命令关闭并重新打开日志文件,并刷新所有表。其他flush-
命令执行类似于xxx
refresh
的功能,但更具体,并且在某些情况下可能更可取。例如,如果您只想刷新日志文件,flush-logs
是比refresh
更好的选择。使用 mysqldump 执行各种
FLUSH
操作的选项:--flush-logs
和--source-data
。使用
RESET BINARY LOGS AND GTIDS
和RESET REPLICA
语句。
启用使用
SHOW BINARY LOG STATUS
、SHOW REPLICA STATUS
和SHOW BINARY LOGS
语句。启用帐户使用
SHOW REPLICAS
、SHOW RELAYLOG EVENTS
和SHOW BINLOG EVENTS
语句请求已对复制源服务器上的数据库进行的更新。此权限也需要使用 mysqlbinlog 选项--read-from-remote-server
(-R
) 和--read-from-remote-source
。将此权限授予复制副本用于连接到当前服务器作为其复制源服务器的帐户。启用从数据库中的表中选择行。
SELECT
语句仅在实际访问表时才需要SELECT
权限。一些SELECT
语句不访问表,可以在没有任何数据库权限的情况下执行。例如,您可以使用SELECT
作为简单的计算器来评估不引用表的表达式SELECT 1+1; SELECT PI()*2;
其他读取列值的语句也需要
SELECT
权限。例如,SELECT
对于在UPDATE
语句中的col_name
=expr
赋值的右侧引用的列或DELETE
或UPDATE
语句的WHERE
子句中命名的列是必需的。启用帐户通过发出
SHOW DATABASE
语句查看数据库名称。没有此权限的帐户只能看到他们拥有某些权限的数据库,如果服务器以--skip-show-database
选项启动,则根本无法使用该语句。警告由于任何静态全局权限都被视为对所有数据库的权限,因此任何静态全局权限都使用户能够使用
SHOW DATABASES
或检查INFORMATION_SCHEMA
的SCHEMATA
表来查看所有数据库名称,但那些在数据库级别通过部分撤销限制的数据库除外。启用使用
SHOW CREATE VIEW
语句。此权限对于与EXPLAIN
一起使用的视图也是必需的。启用使用
SHUTDOWN
和RESTART
语句、 mysqladmin shutdown 命令以及mysql_shutdown()
C API 函数。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
。启用在执行视图或存储程序时设置有效授权 ID。具有此权限的用户可以在视图或存储程序的
DEFINER
属性中指定任何帐户。相应的动态权限是
SET_ANY_DEFINER
和ALLOW_NONEXISTENT_DEFINER
。启用使用
CREATE SERVER
、ALTER SERVER
和DROP SERVER
语句。启用使用 mysqladmin debug 命令。
启用
InnoDB
加密密钥轮换。相应的动态权限是
ENCRYPTION_KEY_ADMIN
。启用执行版本令牌函数。
相应的动态权限是
VERSION_TOKEN_ADMIN
。启用授予和撤销角色、使用
GRANT
语句的WITH ADMIN OPTION
子句,以及ROLES_GRAPHML()
函数结果中非空的<graphml>
元素内容。相应的动态权限是
ROLE_ADMIN
。启用对不允许非
SUPER
帐户的客户端连接的控制。启用使用
KILL
语句或 mysqladmin kill 命令来杀死属于其他帐户的线程。(帐户始终可以杀死自己的线程。)当
SUPER
客户端连接时,服务器不会执行init_connect
系统变量内容。即使由
max_connections
系统变量配置的连接限制已达到,服务器仍接受来自SUPER
客户端的一个连接。处于脱机模式的服务器(
offline_mode
已启用)在下次客户端请求时不会终止SUPER
客户端连接,并接受来自SUPER
客户端的新连接。即使启用了
read_only
系统变量,也可以执行更新。这适用于显式表更新,以及使用诸如GRANT
和REVOKE
的帐户管理语句,这些语句隐式更新表。
用于上述连接控制操作的相应动态权限是
CONNECTION_ADMIN
。
如 第 27.8 节,“存储程序二进制日志记录” 中所述,如果启用了二进制日志记录,您可能还需要
SUPER
权限才能创建或更改存储函数。启用触发器操作。您必须具有表的此权限才能为该表创建、删除、执行或显示触发器。
当触发器被激活时(由具有执行
INSERT
、UPDATE
或DELETE
语句的权限的用户针对与触发器关联的表执行操作),触发器执行需要定义触发器的用户仍然具有该表的TRIGGER
权限。启用更新数据库中表的行。
此权限说明符表示 “无权限。” 它在全局级别与
GRANT
一起使用,以指定诸如WITH GRANT OPTION
之类的子句,而无需在权限列表中命名特定帐户权限。SHOW GRANTS
显示USAGE
以指示帐户在权限级别没有权限。
动态权限是在运行时定义的,与静态权限相反,静态权限是内置于服务器中的。以下列表描述了 MySQL 中可用的每个动态权限。
大多数动态权限是在服务器启动时定义的。其他权限由特定的组件或插件定义,如权限描述中所述。在这种情况下,除非定义它的组件或插件已启用,否则该权限不可用。
某些 SQL 语句可能具有比这里指示的更具体的权限要求。如果是这样,则所讨论的语句的描述将提供详细信息。
启用覆盖旨在防止导致存储对象成为孤儿或导致采用当前为孤儿的存储对象的的操作的安全检查。没有此权限,任何导致 SQL 过程、函数或视图成为孤儿的尝试都会导致错误。使用
CREATE PROCEDURE
、CREATE FUNCTION
、CREATE TRIGGER
、CREATE EVENT
或CREATE VIEW
生成孤儿对象的尝试也需要SET_ANY_DEFINER
以及ALLOW_NONEXISTENT_DEFINER
,以便允许与当前用户不同的定义者。有关详细信息,请参见 孤儿存储对象。
对于双密码功能,此权限启用使用
RETAIN CURRENT PASSWORD
和DISCARD OLD PASSWORD
子句用于ALTER USER
和SET PASSWORD
语句,这些语句适用于您自己的帐户。此权限是操作您自己的辅助密码所必需的,因为大多数用户只需要一个密码。如果要允许帐户操作所有帐户的辅助密码,则应授予该帐户
CREATE USER
权限而不是APPLICATION_PASSWORD_ADMIN
。有关使用双密码的更多信息,请参见 第 8.2.15 节,“密码管理”。
允许审计日志过滤器中的 “abort” 项阻止的查询。此权限由
audit_log
插件定义;参见 第 8.4.5 节,“MySQL Enterprise Audit”。使用
SYSTEM_USER
权限创建的帐户在创建时会自动分配AUDIT_ABORT_EXEMPT
权限。在您执行升级过程时,如果现有帐户没有分配该权限,则也会将AUDIT_ABORT_EXEMPT
权限分配给具有SYSTEM_USER
权限的现有帐户。因此,具有SYSTEM_USER
权限的帐户可用于在审计错误配置后恢复对系统的访问权限。启用审计日志配置。此权限由
audit_log
插件定义;参见 第 8.4.5 节,“MySQL Enterprise Audit”。启用执行
LOCK INSTANCE FOR BACKUP
语句和访问 Performance Schemalog_status
表。注意除了
BACKUP_ADMIN
之外,还需要对log_status
表的SELECT
权限才能访问它。在将 MySQL 9.0 从早期版本就地升级时,会自动向具有
RELOAD
权限的用户授予BACKUP_ADMIN
权限。系统变量
authentication_policy
对CREATE USER
和ALTER USER
语句中与身份验证相关的子句的使用方式施加了某些限制。具有AUTHENTICATION_POLICY_ADMIN
权限的用户不受这些限制的约束。(对于原本不允许的语句会发出警告。)有关
authentication_policy
施加的限制的详细信息,请参阅该变量的说明。通过
PURGE BINARY LOGS
和BINLOG
语句启用二进制日志控制。启用设置系统变量
binlog_encryption
的功能,该变量会激活或停用二进制日志文件和中继日志文件的加密。BINLOG_ADMIN
、SYSTEM_VARIABLES_ADMIN
或SESSION_VARIABLES_ADMIN
权限不会提供此功能。相关系统变量binlog_rotate_encryption_master_key_at_startup
(在服务器重启时自动轮换二进制日志主密钥)不需要此权限。启用执行
CLONE
语句的功能。包括BACKUP_ADMIN
和SHUTDOWN
权限。启用使用
KILL
语句或 mysqladmin kill 命令来杀死属于其他帐户的线程。(帐户始终可以杀死自己的线程。)启用设置与客户端连接相关的系统变量或绕过与客户端连接相关的限制的功能。需要
CONNECTION_ADMIN
才能激活 MySQL Server 的离线模式,这可以通过将系统变量offline_mode
的值更改为ON
来完成。具有
CONNECTION_ADMIN
权限的管理员可以绕过这些系统变量的影响。init_connect
:当CONNECTION_ADMIN
客户端连接时,服务器不会执行系统变量init_connect
的内容。max_connections
:即使达到系统变量max_connections
配置的连接限制,服务器也会接受来自CONNECTION_ADMIN
客户端的一个连接。offline_mode
:处于离线模式(已启用offline_mode
)的服务器不会在下一个客户端请求时终止CONNECTION_ADMIN
客户端的连接,并接受来自CONNECTION_ADMIN
客户端的新连接。read_only
:即使已启用系统变量read_only
,也可以从CONNECTION_ADMIN
客户端执行更新。这适用于显式表更新,以及隐式更新表的帐户管理语句(例如,GRANT
和REVOKE
)。
组复制组成员需要
CONNECTION_ADMIN
权限,以便在涉及的服务器之一处于离线模式时,不会终止组复制连接。如果使用了 MySQL 通信堆栈(group_replication_communication_stack = MYSQL
),则没有此权限,处于离线模式的成员将被逐出组。启用
InnoDB
加密密钥轮换。启用用户管理任何用户的防火墙规则的功能。此权限由
MYSQL_FIREWALL
插件定义;请参阅 第 8.4.7 节,“MySQL Enterprise 防火墙”。具有此权限的用户不受防火墙限制的约束。此权限由
MYSQL_FIREWALL
插件定义;请参阅 第 8.4.7 节,“MySQL Enterprise 防火墙”。启用用户更新其自身防火墙规则的功能。此权限由
MYSQL_FIREWALL
插件定义;请参阅 第 8.4.7 节,“MySQL Enterprise 防火墙”。启用使用
FLUSH OPTIMIZER_COSTS
语句的功能。启用使用
FLUSH PRIVILEGES
语句的功能。启用使用
FLUSH STATUS
语句的功能。启用使用
FLUSH TABLES
语句的功能。启用使用
FLUSH USER_RESOURCES
语句的功能。启用帐户使用
START GROUP REPLICATION
和STOP GROUP REPLICATION
语句启动和停止组复制,更改系统变量group_replication_consistency
的全局设置,以及使用group_replication_set_write_concurrency()
和group_replication_set_communication_protocol()
函数的功能。将此权限授予用于管理作为复制组成员的服务器的帐户。允许用户帐户用于建立组复制的组通信连接。当使用 MySQL 通信堆栈进行组复制(
group_replication_communication_stack=MYSQL
)时,必须将其授予恢复用户。启用帐户激活和停用重做日志存档的功能。
启用使用
ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG
语句启用或停用重做日志记录的功能。请参阅 停用重做日志记录。
启用帐户使用
masking_dictionary_term_add()
和masking_dictionary_term_remove()
组件函数添加和删除字典词条的功能。帐户还需要此动态权限才能使用masking_dictionary_remove()
函数删除完整字典,该函数会删除当前位于mysql.masking_dictionaries
表中的与命名字典关联的所有词条。启用用户或角色及其权限在所有启用
NDB
的 MySQL 服务器之间共享和同步,只要它们加入给定的 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 NO_WRITE_TO_BINLOG TABLE
语句的功能。此权限适用于无密码用户帐户。
对于帐户创建,执行
CREATE USER
创建无密码帐户的用户必须拥有PASSWORDLESS_USER_ADMIN
权限。在复制环境中,
PASSWORDLESS_USER_ADMIN
权限适用于复制用户,并允许复制ALTER USER ... MODIFY
语句,用于配置为无密码身份验证的用户帐户。
有关无密码身份验证的信息,请参见 WebAuthn 无密码身份验证。
对于也具有
SYSTEM_VARIABLES_ADMIN
的用户,PERSIST_RO_VARIABLES_ADMIN
允许使用SET PERSIST_ONLY
将全局系统变量持久化到数据目录中的mysqld-auto.cnf
选项文件。此语句类似于SET PERSIST
,但不会修改运行时全局系统变量值。这使得SET PERSIST_ONLY
适用于配置只读系统变量,这些变量只能在服务器启动时设置。另请参见 第 7.1.9.1 节,“系统变量权限”。
允许帐户充当复制通道的
PRIVILEGE_CHECKS_USER
,并在 mysqlbinlog 输出中执行BINLOG
语句。将此权限授予使用CHANGE REPLICATION SOURCE TO
分配的帐户,以提供复制通道的安全上下文,并处理这些通道上的复制错误。除了REPLICATION_APPLIER
权限之外,您还必须授予帐户执行由复制通道接收或包含在 mysqlbinlog 输出中的事务所需的权限,例如更新受影响的表。有关更多信息,请参见 第 19.3.3 节,“复制权限检查”。允许帐户连接到复制源服务器,使用
START REPLICA
和STOP REPLICA
语句启动和停止复制,并使用CHANGE REPLICATION SOURCE TO
和CHANGE REPLICATION FILTER
语句。将此权限授予副本用于连接到当前服务器作为其复制源服务器的帐户。此权限不适用于组复制;对于组复制,请使用GROUP_REPLICATION_ADMIN
。允许资源组管理,包括创建、更改和删除资源组,以及将线程和语句分配给资源组。具有此权限的用户可以执行与资源组相关的任何操作。
允许将线程和语句分配给资源组。具有此权限的用户可以使用
SET RESOURCE GROUP
语句和RESOURCE_GROUP
优化器提示。允许授予和撤销角色,使用
GRANT
语句的WITH ADMIN OPTION
子句,以及ROLES_GRAPHML()
函数结果中的非空<graphml>
元素内容。需要设置mandatory_roles
系统变量的值。允许持有者查看性能模式表
global_variables
、session_variables
、variables_by_thread
和persisted_variables
中敏感系统变量的值,发出SELECT
语句以返回其值,并在连接的会话跟踪器中跟踪对其的更改。没有此权限的用户无法查看或跟踪这些系统变量值。请参见 持久化敏感系统变量。允许连接到仅允许管理连接的网络接口(请参见 第 7.1.12.1 节,“连接接口”)。
对于大多数系统变量,设置会话值不需要任何特殊权限,任何用户都可以执行此操作以影响当前会话。对于某些系统变量,设置会话值可能会对当前会话之外产生影响,因此这是一个受限操作。对于这些变量,
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 节,“系统变量权限”。
允许在执行视图或存储程序时设置有效的授权 ID。具有此权限的用户可以为
CREATE PROCEDURE
、CREATE FUNCTION
、CREATE TRIGGER
、CREATE EVENT
、ALTER EVENT
、CREATE VIEW
和ALTER VIEW
指定任何帐户作为DEFINER
属性。没有此权限,只能指定有效的身份验证 ID。存储程序以指定帐户的权限执行,因此请确保您遵循 第 27.7 节,“存储对象访问控制” 中列出的风险最小化指南。
允许用户访问所有存储例程(存储过程和函数)的定义和属性,即使是用户未被命名为例程
DEFINER
的例程。此访问包括信息模式
ROUTINES
表的内容。
SHOW_ROUTINE
可以作为具有更受限范围的权限授予,该权限允许访问例程定义。(也就是说,管理员可以撤消不需要全局SELECT
的用户的全局SELECT
,并授予SHOW_ROUTINE
。)这使帐户能够备份存储例程,而无需广泛的权限。由具有此权限的用户发出的查询不受
Rewriter
插件重写的约束(请参见 第 7.6.4 节,“Rewriter 查询重写插件”)。此权限应授予发出不应该被重写的管理或控制语句的用户,以及
PRIVILEGE_CHECKS_USER
帐户(请参见 第 19.3.3 节,“复制权限检查”),用于应用来自复制源的语句。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 Audit”),则具有SYSTEM_USER
权限的帐户将自动分配AUDIT_ABORT_EXEMPT
权限,该权限允许其查询即使在过滤器中配置的“abort”项会阻止它们的情况下也能执行。因此,具有SYSTEM_USER
权限的帐户可用于在审计配置错误后重新获得对系统的访问权限。影响以下操作和服务器行为
启用运行时系统变量更改
启用使用
SET GLOBAL
和SET PERSIST
对全局系统变量进行服务器配置更改。如果用户还具有
PERSIST_RO_VARIABLES_ADMIN
,则可以使用SET PERSIST_ONLY
对全局系统变量进行服务器配置更改。启用设置需要特殊权限的受限会话系统变量。实际上,
SYSTEM_VARIABLES_ADMIN
意味着SESSION_VARIABLES_ADMIN
,而无需显式授予SESSION_VARIABLES_ADMIN
.
另请参见 第 7.1.9.1 节,“系统变量权限”。
启用对全局事务特性的更改(参见 第 15.3.7 节,“SET TRANSACTION 语句”)。
当
table_encryption_privilege_check
启用时,允许用户覆盖默认加密设置;请参见定义模式和通用表空间的加密默认值。启用遥测日志配置。此权限由
telemetry_log
插件定义,该插件通过 AWS 上的 HeatWave 部署。启用使用特权连接连接到服务器。当达到
thread_pool_max_transactions_limit
定义的限制时,不允许新的连接,除非由thread_pool_longrun_trx_limit
覆盖。特权连接忽略事务限制并允许连接到服务器以增加事务限制,删除限制或终止正在运行的事务。此权限默认情况下不会授予任何用户。要建立特权连接,启动连接的用户必须具有TP_CONNECTION_ADMIN
权限。当达到
thread_pool_max_transactions_limit
定义的限制时,特权连接可以执行语句并启动事务。特权连接放置在Admin
线程组中。请参见特权连接。在复制源服务器上将
gtid_next
系统变量设置为AUTOMATIC:
或TAG
UUID:
所需。此外,至少需要一个TAG
:NUMBERSYSTEM_VARIABLES_ADMIN
、SESSION_VARIABLES_ADMIN
或REPLICATION_APPLIER
来将gtid_next
设置为源上的其中一个值。为了将
gtid_next
设置为AUTOMATIC:
,TAG
REPLICATION_CHECKS_APPLIER
也必须具有此权限以及REPLICATION_APPLIER
权限。在启动复制应用程序线程时,会检查这一点。此权限还要求设置
gtid_purged
服务器系统变量。有关使用标记的 GTID 的更多信息,请参见
gtid_next
的描述,以及第 19.1.4 节“在联机服务器上更改 GTID 模式”。启用版本令牌函数的执行。此权限由
version_tokens
插件定义;请参见第 7.6.6 节“版本令牌”。启用
XA RECOVER
语句的执行;请参见第 15.3.8.1 节“XA 事务 SQL 语句”。在 MySQL 9.0 之前,任何用户都可以执行
XA RECOVER
语句来发现未完成的已准备好的 XA 事务的 XID 值,这可能会导致由启动事务的用户以外的用户提交或回滚 XA 事务。在 MySQL 9.0 中,仅允许具有XA_RECOVER_ADMIN
权限的用户执行XA RECOVER
,预计该权限仅授予需要它的管理用户。例如,这可能是 XA 应用程序管理员的情况,如果应用程序崩溃并且需要查找应用程序启动的未完成事务以使其回滚。此权限要求阻止用户发现除自身以外的未完成的已准备好的 XA 事务的 XID 值。它不会影响 XA 事务的正常提交或回滚,因为启动事务的用户知道其 XID。
为帐户授予其需要的权限是一个好主意。在授予FILE
和管理权限时应格外小心
FILE
可能会被滥用,以将 MySQL 服务器可以在服务器主机上读取的任何文件读入数据库表。这包括所有世界可读文件和服务器数据目录中的文件。然后可以使用SELECT
访问该表,以将内容传输到客户端主机。GRANT OPTION
使用户能够将他们的权限授予其他用户。具有不同权限并且具有GRANT OPTION
权限的两个用户能够组合权限。ALTER
可用于通过重命名表来破坏权限系统。SHUTDOWN
可能会被滥用,通过终止服务器来完全拒绝其他用户服务。PROCESS
可用于查看当前执行语句的纯文本,包括设置或更改密码的语句。SUPER
可用于终止其他会话或更改服务器的操作方式。针对
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
选项)。在
global_grants
中列出的动态权限分配是持久的。它们在服务器关闭时不会被删除。
示例:以下语句授予用户 u1
控制副本(包括组复制)上的复制以及修改系统变量所需的权限
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 提供的权限”。
在 MySQL 9.0 中,以前需要 SUPER
权限的许多操作也与范围更有限的动态权限相关联。(有关这些权限的说明,请参阅 第 8.2.2 节,“MySQL 提供的权限”。)可以通过授予关联的动态权限而不是 SUPER
来允许帐户执行此类操作。此更改通过使 DBA 能够避免授予 SUPER
并根据允许的操作更紧密地定制用户权限来提高安全性。 SUPER
现在已弃用;预计它将在 MySQL 的未来版本中被删除。
当 SUPER
被删除时,以前需要 SUPER
的操作将失败,除非授予了 SUPER
的帐户迁移到适当的动态权限。使用以下说明来完成该目标,以便在 SUPER
被删除之前帐户已准备好。
执行此查询以识别被授予
SUPER
的帐户。SELECT GRANTEE FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE PRIVILEGE_TYPE = 'SUPER';
对于前面查询确定的每个帐户,确定它需要
SUPER
执行的操作。然后授予与这些操作相对应的动态权限,并撤销SUPER
。例如,如果
'u1'@'localhost'
需要SUPER
进行二进制日志清除和系统变量修改,这些语句将对该帐户进行必要的更改。GRANT BINLOG_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'u1'@'localhost'; REVOKE SUPER ON *.* FROM 'u1'@'localhost';
修改完所有适用的帐户后,第一步中的
INFORMATION_SCHEMA
查询应产生一个空结果集。