选authid current_user是实现最小权限的唯一可行路径；默认authid definer使过程以创建者身份执行所有sql（含execute immediate），调用者可借其权限越界操作，而authid current_user强制按调用者权限校验，确保“谁调用、谁负责”。
直接结论：选 AUTHID CURRENT_USER 是最小权限落地的唯一可行路径；默认的定义者权限（AUTHID DEFINER）本质是权限放大器，不是安全机制。
EXECUTE IMMEDIATE 执行时权限被绕过？其实是定义者权限在生效
这不是 bug，是 Oracle 默认行为：只要没显式声明 AUTHID CURRENT_USER，过程里所有 SQL —— 包括 EXECUTE IMMEDIATE —— 都以创建者身份运行。调用者哪怕只有 SELECT 权限，也能借过程删表、改数据，只要创建者有这权限。
常见错误现象：
- 过程能编译成功，但调用时报
ORA-01031: insufficient privileges（加了AUTHID CURRENT_USER后才暴露真实权限缺口） - 过程里查其他用户的表失败，即使调用者已被授了
SELECT ON other_user.table，但过程没加AUTHID CURRENT_USER，权限检查不走调用者上下文 - DBA 给用户开了
DBA角色，过程里仍查不到DBA_TABLES—— 因为定义者权限下角色无效，必须显式授权
什么时候必须用 AUTHID CURRENT_USER
核心判断标准：你是否希望「谁调用、谁负责」—— 即过程行为受调用者实际权限约束。
- 多租户或分 Schema 场景：不同用户调用同一过程，应只操作自己 Schema 下的表（如
INSERT INTO orders，不加 schema 前缀），这时必须用AUTHID CURRENT_USER，否则默认走定义者 Schema - 需要依赖角色权限：调用者通过
HR_ROLE拥有SELECT ON employees，定义者权限下该角色不生效，只有AUTHID CURRENT_USER才让角色权限参与检查 - 最小权限实践：你明确不想让过程成为“权限跳板”，例如禁止普通用户通过过程执行 DDL 或跨 Schema 修改
- 白名单校验配合使用：过程内做表名/字段名校验后，再用
EXECUTE IMMEDIATE执行，此时权限必须落在调用者身上，否则校验形同虚设
定义者权限（AUTHID DEFINER）只剩两个合理用途
不是不能用，而是适用场景极窄，且需清醒认知风险：
- 运维类集中管理过程：DBA 写一个
cleanup_logs过程，所有应用用户都能调用，但实际清理动作始终以 DBA 身份执行 —— 此时你主动要的是权限提升，而非限制 - 封装不可变逻辑：过程只读取本 Schema 固定视图（如
v$session）、不做 DML、不拼接用户输入，且调用者无需任何对象权限 —— 本质是把过程当函数用
注意：AUTHID DEFINER 下，GRANT EXECUTE ON proc TO user 只控制能否调用过程，不控制过程内部能做什么；真正的权限边界在创建者身上，不是在授权语句里。
加 AUTHID CURRENT_USER 后，权限检查变严格，但不是万能
它只解决「谁来检查权限」的问题，不解决「有没有权限」的问题。加了之后，常见掉坑点：
- 调用者必须有显式对象权限，不能依赖角色 —— 错！
AUTHID CURRENT_USER下角色权限有效，但需确认角色确实被授予且启用（SELECT * FROM SESSION_ROLES） - 过程里访问
other_user.table，只给调用者SELECT ON other_user.table就够 —— 对，但授权必须由other_user或 DBA 执行，不能由过程创建者代授 - 过程里建临时表失败，报
ORA-01950: no privileges on tablespace—— 缺默认表空间，执行ALTER USER username DEFAULT TABLESPACE users - 动态 SQL 拼接表名后执行，仍报权限不足 —— 表名校验通过不代表权限已授，校验和授权是两件事
最易被忽略的一点：加了 AUTHID CURRENT_USER，过程本身仍需被授予 EXECUTE 权限，但这权限不再赋予调用者“继承创建者权限”的能力 —— 它只是打开了一扇门，门后有没有路，得看调用者自己有没有脚。
