oracle无“execute any package”权限，execute any procedure仅覆盖standalone过程及package specification中声明的public子程序，不包含package body私有过程；调用package必须显式授予grant execute on schema.package to user。
不能直接授予“执行任意 package 封装过程”的权限——oracle 没有类似 execute any procedure 这样的权限能覆盖所有 package 中的 procedure（注意：execute any procedure 实际上**不包含 package body 中的私有过程，也不自动授权对 package specification 的访问**，且需谨慎使用）。
为什么 EXECUTE ANY PROCEDURE 不等于“能执行任意 package 过程”
这个权限看似宽泛，但实际行为受限：
- 它允许调用其他用户 schema 下的 standalone procedure/function，但对
package只作用于其 specification 中声明的 public 子程序；package body 内的私有过程仍不可见 - 调用方必须先有对该 package specification 的
EXECUTE权限（哪怕已授EXECUTE ANY PROCEDURE），否则报错ORA-04068: existing state of packages has been discarded或更常见的ORA-00942: table or view does not exist（实际是权限不足） - 它不隐含对 package 依赖对象（如表、序列）的访问权，运行时仍可能因缺少
SELECT/INSERT等权限失败
真正可行的方案：按需显式授权 EXECUTE 到具体 package
这是生产环境唯一安全、可审计、符合最小权限原则的做法：
- 对每个需开放的 package，执行：
GRANT EXECUTE ON schema_name.package_name TO target_user;
- 若需批量授权（例如 schema A 下所有 package），可用动态 SQL 生成语句：
SELECT 'GRANT EXECUTE ON ' || owner || '.' || object_name || ' TO target_user;' FROM dba_objects WHERE owner = 'SCHEMA_A' AND object_type = 'PACKAGE';
再手动审查后执行 - 注意：只授权
PACKAGE类型对象（不是PACKAGE BODY），因为执行权限只在 spec 层控制
误用 EXECUTE ANY PROCEDURE 的典型后果
它常被当作“快捷方式”，但会埋下隐患：
- 授予后，用户可调用所有 schema 的 standalone 过程（包括 DBA 维护用的内部过程），存在越权风险
- 无法区分“调用某个业务 package”和“执行任意存储过程”，违反职责分离原则
- 审计日志中只记录“执行了某过程”，但无法追溯是否属于预期业务 package 范围
- 撤销困难：一旦授出，需逐个 revoke，且容易遗漏
真正的复杂点不在语法，而在于权限边界的理解——Oracle 的 package 权限模型是分层的（spec vs body、public vs private、owner vs caller），任何想绕过显式授权的捷径，最终都会在依赖解析、失效重编译或审计合规上暴露问题。
