第二阶段(权限检查) - xiaoboluo768/mysql-system-schema GitHub Wiki
- 当客户端与MySQL Server 建立连接之后，Server 进入权限访问控制的第2阶段。在第2阶段中，客户端发送给服务端的每个请求，服务端都会检查请求操作的类型，然后检查是否有足够的访问权限来执行请求操作。该检查工作依赖于mysql schema下的user、db、tables_priv、columns_priv、procs_priv、proxies_priv权限表中存放的权限信息。
- user：该表中的权限作用范围是全局的，所以该表中相应权限类型列值为'Y'时，就表示表示对数据库实例中的所有数据库表都有该权限，所以，在大多数时候，我们需要根据具体的业务环境需求来给定需要访问的数据库对应的权限，而不是投方便直接给所有库所有表的权限（关于如何给定权限，请参考上文提到的权限分类）
- user列为空时表示匿名用户，非空值必须匹配字符串字面本身表示的用户名，用户名不能使用通配符
- host列值不允许为空(虽然授权语句和创建用户的语句可以只写用户名而不写主机名，但实际上存储在表中时会被转换为%)，但可以使用通配符（%和_：%表示任意主机，_表示主机名中的任意一个字符），可以使用like关键字来配合通配符进行匹配
- db：该表中的权限作用范围是数据库级别，对应数据库内的所有对象：
- user列和host列的表现形式要求与user表相同
- PS：与user表类似，Server会在启动时就将db表中的内容读入内存，并在内存中进行排序，根据Host，Db和User 三列对db表中的数据进行排序。排序会将最具体的值放在最前面，将最不具体的值放到最后，当Server进行用户匹配查找时，会使用第一个匹配行进行许可
- tables_priv，columns_priv和procs_priv：这三张表中记录着表级别权限、列级别权限、线程级别权限：
- user列和host列的表现形式要求与user表相同
- Db，Table_name，Column_name和Routine_name列不能包含通配符或为空值
- PS：与user表类似，Server会在启动时就将db表中的内容读入内存，并在内存中进行排序，根据Host，Db和User三列对tables_priv，columns_priv和procs_priv表数据进行排序
- 当一个客户端连接在进行第二阶段权限验证时，首先检查user表，如果所检查权限是user表特有的(其他权限表没有的权限类别)，则user表中允许执行则Server 授予客户端访问权限，否则直接拒绝而不会继续检查其他权限表(因为其他权限表不具备该权限列表，无需检查)，如果所检查权限类别除了在user表之外，在其他权限表中也具有该权限类别(例如：DML权限)，则即时在user表中不允许(毕竟user表中的权限是表示是否具有全局权限的意思)，也会继续往下检查db表，然后再检查tables_priv表，以此类推。
- PS：
* 如果某客户端在user表中类似DML权限不足，而在其他db、tables_priv、columns_priv表中都没有找到对应的user,host列记录（则表示用户在所有权限表中都没有对应操作类型的权限），则客户端访问被拒绝，返回无访问权限提示信息
* grant语句在授予用户权限时，授予库级别权限时，数据库不需要事先存在即可授权成功，但如果是对表级别对象授权，则表需要事先存在，否则授权失败，提示表不存在的报错信息
* 对于存储程序的请求操作，Server 使用procs_priv表检查权限，而不是tables_priv和columns_priv表
- 上文中提及的权限检查逻辑，可以使用如下布尔型的伪代码来表示：
global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges
OR routine privileges- PS：某些类型的一个语句可以需要请求多个类型的权限，例如：INSERT...SELECT，该语句需要请求INSERT和SELECT两个权限，而这两个权限可能在授予用户的时候授予范围不同，假如INSERT授予的是全局范围权限，而SELECT是授予的db级别的权限，此时，INSERT权限是保存在user表中的，SELECT权限是保存在db表中的，那么也就是说，这个时候Server需要分两次查询之后将两个表中记录的权限信息进行组合，然后再用于判断用户是否具INSERT...SELECT语句的访问请求权限，并返回相应的请求结果。如果任意一个权限不满足，则拒绝访问
上一篇：第一阶段(帐号和密码认证) |下一篇：权限变更的影响