SQL Server中应使用WITH EXECUTE AS OWNER显式指定执行上下文，避免EXECUTE AS SELF；MySQL无EXECUTE AS机制，权限控制不可靠，需依赖应用层代理或视图+行级策略；PostgreSQL的SECURITY DEFINER函数须严格收敛定义者权限并禁用危险操作。
SQL Server 中如何给存储过程设最小权限
存储过程本身不继承调用者权限，但默认执行时以 EXECUTE AS CALLER 模式运行——也就是说，谁执行它，就用谁的权限查表。这很危险：一个普通用户如果能执行某个存储过程，而该过程内部 SELECT * FROM sys.tables，那他就可能间接看到不该看的元数据。
正确做法是显式指定执行上下文。常见且安全的方式是用 EXECUTE AS OWNER 或 EXECUTE AS 'username'，让过程始终以固定高权限账户运行，而调用者只需拥有 EXECUTE 权限即可。
- 创建过程时加上
WITH EXECUTE AS OWNER，确保逻辑层和数据访问层权限分离 - 避免用
EXECUTE AS SELF，它会把创建者的身份固化下来，换人维护时容易出权限漂移 - 如果过程只读，且底层表已对专用账户授权，就别在过程里再
GRANT SELECT—— 这属于冗余操作，还可能掩盖实际缺失的权限
MySQL 存储过程中无法限制调用者访问表？
MySQL 的存储过程没有 SQL Server 那样的 EXECUTE AS 机制。它的权限检查发生在语句执行时，不是过程定义时。也就是说，即使你用低权限账户创建了过程，只要调用者自己有对应表的 SELECT 权限，过程里照样能查出来。
真要隔离，只能靠“绕开直接表访问”：把数据查询封装进视图 + 行级权限（MySQL 8.0+），或改用函数返回结果集（但函数不能执行 DML）。更现实的做法是——不用存储过程做权限边界，改用应用层代理。
- MySQL 5.7 及以下版本，存储过程权限控制基本不可靠，别指望它挡住越权访问
- MySQL 8.0 引入角色和行级安全策略（
CREATE POLICY），但仅适用于SELECT，且不作用于存储过程内部语句 - 若必须用过程，至少把敏感字段过滤掉，比如过程里写
SELECT id, name FROM users WHERE status = 'active'，而不是SELECT *
为什么需要单独建个执行账户，而不是直接给应用用户赋权
因为应用用户账号（比如 app_user）通常长期存在、多服务共用、密码轮换不及时；而存储过程的执行逻辑是固定的。一旦把 SELECT、INSERT 等权限直接给到 app_user，攻击者拿到这个账号后就能绕过所有过程封装，直连表操作。
专用执行账户（如 proc_executor）只被授予特定过程的 EXECUTE 权限，以及过程内部涉及的极少数表的最小必要权限（比如只给 UPDATE 某几个字段），且该账户禁止交互式登录、不配密码策略外的其他权限。
- 创建账户时用
CREATE USER 'proc_executor'@'localhost' IDENTIFIED BY 'xxx'，并立即REVOKE ALL PRIVILEGES ON *.* FROM 'proc_executor'@'localhost' - 只显式
GRANT EXECUTE ON PROCEDURE mydb.calc_report TO 'proc_executor'@'localhost'，再加一条GRANT SELECT(id,amount) ON mydb.orders TO 'proc_executor'@'localhost' - 应用连接字符串里仍用
app_user，但在调用过程前先SET ROLE 'proc_executor'（MySQL 8.0+）或通过中间件切换上下文
PostgreSQL 中 function SECURITY DEFINER 是双刃剑
SECURITY DEFINER 让函数以定义者身份运行，看起来是权限控制利器，但极易因疏忽变成提权入口。比如一个函数声明为 SECURITY DEFINER，但内部执行了 COPY ... TO '/tmp/pwned'，攻击者只要能触发该函数，就能写任意文件。
它真正适用的场景只有一个：函数逻辑完全可控、不拼接用户输入、不调用外部命令、且定义者账户本身权限已被严格收敛。
- 永远不要对接受
text参数的函数设SECURITY DEFINER，除非你用format()+quote_literal()做了完整转义 - PostgreSQL 14+ 支持
SECURITY DEFINER函数的SET search_path TO 'pg_temp'，强制隔离 schema，建议默认加上 - 检查已有函数：运行
SELECT proname, prosecdef, proconfig FROM pg_proc WHERE prosecdef，逐个确认是否真有必要保留SECURITY DEFINER
权限控制最麻烦的地方不在语法，而在“谁在什么上下文里调用了什么”。哪怕 SQL Server 的 EXECUTE AS OWNER 写对了，如果 owner 账户本身有 db_owner 角色，那整个控制就形同虚设。得一层层往回推：过程 → 执行账户 → 该账户的成员角色 → 角色拥有的权限 → 权限覆盖的范围。漏掉任意一环，都可能被绕过。
