Oracle中唯一可靠方式是直接授予EXECUTE ON具体package，因无“执行任意package过程”的开关式权限；必须按需显式授权，如GRANT EXECUTE ON app_data.employees_pkg TO app_user，严禁使用EXECUTE ANY PROCEDURE。
直接授予 EXECUTE ON package 是唯一可靠方式
Oracle 没有“限制用户只能执行某几个 package”的开关式权限，必须靠“只授所需”来实现。你不能靠拒绝（REVOKE）来约束——因为默认用户啥都不能做，真正起作用的是你 GRANT 了什么。
常见错误是先给 EXECUTE ANY PROCEDURE，再试图用 REVOKE 拦住非目标 package——这行不通。该权限本身不区分 package 或 standalone 过程，且 REVOKE EXECUTE ANY PROCEDURE 会一并收回对所有 standalone 过程的调用权，破坏已有逻辑。
- 只对业务必需的 package 显式授权：
GRANT EXECUTE ON app_data.employees_pkg TO app_user; - 绝不授予
EXECUTE ANY PROCEDURE给应用用户 - 确保目标用户没有
SELECT、INSERT等对象权限——否则可绕过 package 直接操作表
为什么不能靠角色或 WITH GRANT OPTION 控制范围
角色（如 CONNECT、RESOURCE）只含系统权限，不包含对具体 package 的 EXECUTE 权限；而 WITH GRANT OPTION 在对象权限中允许被授权者转授，但 Oracle 不允许对 EXECUTE ON PACKAGE 使用该选项——语句会报错 ORA-01927: cannot revoke privileges you did not grant 或直接拒绝解析。
这意味着：你无法通过中间角色分发 package 执行权，也无法让 app_admin_user 帮你批量授予权限。所有 GRANT EXECUTE ON ... 必须由具有相应权限的管理员（如 app_data owner 或 DBA）直接执行。
-
GRANT EXECUTE ON app_data.admin_pkg TO app_admin_user WITH GRANT OPTION;→ 语法错误，Oracle 不支持 - 创建自定义角色并
GRANT EXECUTE ON ...到该角色 → 可行，但角色本身不缩小权限范围，只是封装手段 - 依赖 profile 限制 CPU 或 session 时间 → 与执行范围无关，无法阻止调用非法 package
检查用户实际能调用哪些 package
用户能否调用某个 package，取决于两个条件同时满足：对该 package specification 有 EXECUTE 权限，且 package 本身有效（未失效）。仅看 DBA_TAB_PRIVS 不够，还要确认 package 是否可访问。
运行以下查询可列出用户显式获得 EXECUTE 权限的所有 package：
SELECT owner, table_name AS package_name
FROM dba_tab_privs
WHERE grantee = 'APP_USER'
AND privilege = 'EXECUTE'
AND owner != 'SYS' -- 排除系统包
AND table_name IN (
SELECT object_name FROM dba_objects
WHERE owner = dba_tab_privs.owner
AND object_type = 'PACKAGE'
);若返回为空，则该用户当前无法执行任何 package；若返回结果多于预期，说明存在冗余授权，应立即 REVOKE EXECUTE ON ... 清理。
- 注意：
DBA_TAB_PRIVS不反映通过角色继承的权限，需结合DBA_ROLE_PRIVS和角色所含权限交叉验证 -
ALL_OBJECTS中STATUS = 'VALID'仅表示编译通过，不代表用户有权执行 - 调用时出现
ORA-00942很可能不是表不存在，而是缺少对 package 的EXECUTE权限
应用连接池场景下容易忽略的权限边界
中间层以 app_user 身份连接数据库，所有 SQL 和 PL/SQL 都在该用户会话内执行。此时 package 内部的代码仍以 app_user 身份运行——它能做什么，完全取决于 app_user 自身的对象权限，而非 package owner 的权限。
这意味着：即使 employees_pkg 由 app_data 创建，只要 app_user 没有 SELECT 权限，package 里任何 SELECT * FROM employees 都会失败。你必须在 package 内部用 AUTHID DEFINER（默认）或显式加 DEFINER，才能让 package 以 owner 权限运行——但这又带来新的安全风险：一旦 package 有注入漏洞，攻击者可借 app_data 权限越权。
- 生产环境推荐
AUTHID CURRENT_USER，强制 package 严格遵循调用者权限模型 - 若必须用
DEFINER，则需确保 package 内部不拼接用户输入，且所有 DML 都走白名单校验 - 连接池重用会话后，包变量（如
g_session_id）会被重置，但权限不会——权限绑定的是用户名，不是连接实例
