execute as owner 是最常被误用的权限放大器，不是加固手段；一旦启用，调用者就拥有了 owner 的全部权限，哪怕只查日志表也能删 sys.tables，必须避免除非 owner 是专设低权限账号，且跨库操作须禁用 trustworthy 并改用证书签名。
EXECUTE AS OWNER 是最常被误用的权限放大器，不是加固手段。一旦启用，调用者就拥有了 owner 的全部权限——哪怕只是想查一张日志表，也能顺手删掉 sys.tables。
SQL Server 中 EXECUTE AS 导致权限意外扩散
存储过程默认以调用者身份运行，加了 EXECUTE AS 后，执行上下文就切换到指定主体。问题出在“指定谁”：EXECUTE AS OWNER 看似省事，但 owner 往往是 db_owner 或 sa，等于把钥匙直接交给路人。
- 永远避免
EXECUTE AS OWNER，除非 owner 是专设的、仅授予SELECT权限的账号（如proc_reader） - 显式写死低权限用户：
EXECUTE AS 'proc_executor'，且该用户只被GRANT过过程内真实用到的权限（比如只对audit_log有INSERT） - 跨库操作必须关掉
TRUSTWORTHY ON（默认是OFF），否则EXECUTE AS可穿透到其他数据库——这时得用证书签名或登录模拟，不能靠上下文切换
MySQL 存储过程因 DEFINER 设置过高引发提权
MySQL 没有 EXECUTE AS，靠 DEFINER + SQL SECURITY DEFINER 控制执行身份。但很多人建过程时没指定 DEFINER，结果默认成了 root@'%'，等于给所有调用者开了 root 后门。
- 创建时必须显式声明低权限
DEFINER，例如DEFINER='proc_runner'@'localhost'，并确认该账号只对涉及的表有SELECT或UPDATE -
SQL SECURITY DEFINER是默认值，它不等于“授权”，只是固定执行身份；真正起作用的是DEFINER账号本身的权限 - 如果过程逻辑本身只需要调用者权限（比如只读自己能访问的行），改用
SQL SECURITY INVOKER更安全，权限检查发生在运行时，不会绕过调用者限制
PostgreSQL SECURITY DEFINER 函数的 search_path 注入风险
PostgreSQL 的 SECURITY DEFINER 函数确实能换角色，但函数体内的对象引用默认不带 schema，且会继承调用者的 search_path。攻击者只要提前 SET search_path = 'malicious_schema, public'，就能让函数执行同名恶意函数或表。
- 所有对象引用必须显式带上 schema，例如写成
public.users而不是users - 函数开头第一句就得重置
search_path：SET search_path = 'pg_catalog', 'public'; - 函数必须由 schema owner 创建，且该 owner 对目标 schema 仅有
USAGE权限，不能有CREATE权限，否则攻击者可能注入新对象
EXECUTE AS 或 SECURITY DEFINER 就算完成了安全加固。
