Documentation Home
MySQL 8.0 参考手册  / 第 6 章 安全  / 6.2 访问控制和账户管理  /  6.2.6 访问控制,第 2 阶段:请求验证

6.2.6 访问控制,第 2 阶段:请求验证

服务器接受连接后,进入访问控制的第 2 阶段。对于您通过连接发出的每个请求,服务器都会确定您要执行的操作,然后检查您的权限是否足够。这就是授权表中的特权列发挥作用的地方。这些权限可以来自userdbtables_privcolumns_privprocs_priv 表中的任何一个。(您可能会发现参考 第 6.2.3 节“授权表”很有帮助,其中列出了每个授权表中的列。)

user表授予全局权限。帐户的 user表行指示在全局基础上应用的帐户权限,无论默认数据库是什么。例如,如果user 表授予您DELETE 权限,您可以从服务器主机上任何数据库中的任何表中删除行。明智的做法是只将表中的权限授予 user需要它们的人,例如数据库管理员。对于其他用户,将user表中的所有权限保留为'N' 并仅授予更特定级别的权限(对于特定数据库、表、列或例程)。

db表授予特定于数据库的权限。此表的范围列中的值可以采用以下形式:

  • 空白User值与匿名用户匹配。非空值按字面匹配;用户名中没有通配符。

  • 通配符%and _可以用在 HostandDb列中。这些与使用运算符执行的模式匹配操作具有相同的含义LIKE。如果您想在授予权限时按字面意思使用任一字符,则必须使用反斜杠将其转义。例如,要将下划线字符 ( _) 作为数据库名称的一部分,\_ 请在GRANT语句中指定它。

  • 一个'%'或空白Host 值表示任何主机。

  • 一个'%'或空白Db值表示任何数据库。

服务器将db表读入内存,并在读取表的同时进行排序 userdb服务器根据HostDbUserscope 列对表进行排序 。与user表格一样,排序将最具体的值放在最前面,最不具体的值放在最后,当服务器查找匹配行时,它会使用它找到的第一个匹配项。

、和表授予特定于表tables_priv、 特定于列和特定于例程的权限。这些表的范围列中的值可以采用以下形式: columns_privprocs_priv

  • 通配符%_可以在 Host列中使用。这些与使用运算符执行的模式匹配操作具有相同的含义 LIKE

  • 一个'%'或空白Host 值表示任何主机。

  • DbTable_nameColumn_nameRoutine_name不能包含通配符或为空。

服务器根据、 和列对tables_privcolumns_priv和表进行 排序。这类似于表排序,但更简单,因为只有列可以包含通配符。 procs_privHostDbUserdbHost

The server uses the sorted tables to verify each request that it receives. For requests that require administrative privileges such as SHUTDOWN or RELOAD, the server checks only the user table row because that is the only table that specifies administrative privileges. The server grants access if the row permits the requested operation and denies access otherwise. For example, if you want to execute mysqladmin shutdown but your user table row does not grant the SHUTDOWN privilege to you, the server denies access without even checking the db table. (The latter table contains no Shutdown_priv column, so there is no need to check it.)

For database-related requests (INSERT, UPDATE, and so on), the server first checks the user's global privileges in the user table row. If the row permits the requested operation, access is granted. If the global privileges in the user table are insufficient, the server determines the user's database-specific privileges from the db table:

  • The server looks in the db table for a match on the Host, Db, and User columns.

  • The Host and User columns are matched to the connecting user's host name and MySQL user name.

  • The Db column is matched to the database that the user wants to access.

  • If there is no row for the Host and User, access is denied.

After determining the database-specific privileges granted by the db table rows, the server adds them to the global privileges granted by the user table. If the result permits the requested operation, access is granted. Otherwise, the server successively checks the user's table and column privileges in the tables_priv and columns_priv tables, adds those to the user's privileges, and permits or denies access based on the result. For stored-routine operations, the server uses the procs_priv table rather than tables_priv and columns_priv.

Expressed in boolean terms, the preceding description of how a user's privileges are calculated may be summarized like this:

global privileges
OR database privileges
OR table privileges
OR column privileges
OR routine privileges

It may not be apparent why, if the global privileges are initially found to be insufficient for the requested operation, the server adds those privileges to the database, table, and column privileges later. The reason is that a request might require more than one type of privilege. For example, if you execute an INSERT INTO ... SELECT statement, you need both the INSERT and the SELECT privileges. Your privileges might be such that the user table row grants one privilege global and the db表行授予其他专门针对相关数据库。在这种情况下,您拥有执行请求所需的权限,但服务器无法单独从您的全局权限或数据库权限中分辨出来。它必须根据组合的权限做出访问控制决策。