mysql中触发器的安全性与访问控制

触发器执行时用的是定义者（DEFINER）的权限；默认 SQL SECURITY 为 DEFINER，以创建者身份运行，不校验调用者权限，存在越权风险，而 INVOKER 模式则受当前用户权限约束。

触发器执行时用的是谁的权限？

MySQL 触发器在执行时不检查调用者的权限，而是严格依赖定义时指定的 SQL SECURITY 属性。默认是 DEFINER，意味着触发器以创建者（即 DEFINER 用户）的身份运行，哪怕当前执行 INSERT/UPDATE/DELETE 的用户只有最低权限，只要语句本身合法，触发器内部的 SQL 仍会以定义者权限执行。

这带来明显风险：一个低权限用户通过合法 DML 操作，可能间接触发高权限逻辑（如向审计表写入、调用 sys_exec() 插件、删日志表等）。

• SQL SECURITY DEFINER：最常见，也最危险——只要定义者有权限，触发器就能越权操作
• SQL SECURITY INVOKER：触发器内所有操作受当前执行用户的权限约束，更安全但可能因权限不足导致触发失败
• 定义者必须对触发器中涉及的所有表拥有对应权限（如触发器里有 INSERT INTO audit_log，定义者就得有 audit_log 的 INSERT 权限）

如何查出数据库里有哪些 DEFINER 是高危账户的触发器？

直接查 information_schema.TRIGGERS 表，重点关注 DEFINER 字段是否为 'root'@'%'、'admin'@'localhost' 等强权限账户，以及 EVENT_MANIPULATION 是否包含敏感动作（如 DELETE、TRUNCATE）。

SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_MANIPULATION,         ACTION_STATEMENT, DEFINER  FROM information_schema.TRIGGERS  WHERE DEFINER LIKE '%root@%' OR DEFINER LIKE '%admin@%';

注意：ACTION_STATEMENT 是原始 SQL 文本，需人工审查是否含危险函数（如 LOAD_FILE()、UNION SELECT …… INTO OUTFILE）、跨库操作或硬 编码 密码。

触发器里能绕过行级权限控制吗？

能，而且很彻底。MySQL 原生不支持行级访问控制（RLS），而触发器在服务端执行，完全不受客户端权限模型限制。例如：

• 某用户仅被授权查询 orders 表中 status = 'pending' 的行（靠应用层过滤），但触发器若在 AFTER INSERT 中执行 SELECT * FROM orders WHERE user_id = NEW.user_id，就会读到该用户本不该看到的已发货订单
• 使用 mysql.sys 或自定义函数时，只要定义者有权限，触发器就能拿到系统变量、进程列表甚至文件内容
• 触发器无法感知列级权限（COLUMN_PRIVILEGES），对被屏蔽的列仍可读写（只要表级权限允许）

生产环境启用触发器前必须做的三件事

不是加个触发器就完事，尤其在权限模型复杂或接入了 ProxySQL / MaxScale 的场景下：

• 显式声明 SQL SECURITY INVOKER，除非业务逻辑确实需要定义者权限（如统一写审计日志到中心库）
• 禁用 log_bin_trust_function_creators = OFF（默认值），防止用户创建带副作用的函数再被触发器调用；如必须启用，只给可信账号 SUPER 权限
• 所有触发器必须走 DDL 变更流程审核：检查 ACTION_STATEMENT 是否含子查询、临时表、外部函数；确认没有循环触发（如 A 表触发器改 B 表，B 表触发器又改 A 表）

最常被忽略的一点：触发器错误不会中断主 DML 语句（除非是 BEFORE 触发器抛出异常），但错误日志只写在 MySQL 错误日志里，且默认不记录具体哪条语句触发了它——这意味着权限越界行为可能长期静默发生。