WITH ADMIN OPTION用于系统权限/角色，授权后回收不级联；WITH GRANT OPTION用于对象权限，回收时级联撤销下游权限。
ADMIN OPTION 本质是“授予权力的权力”，不是“授权本身”
Oracle 中 WITH ADMIN OPTION 附加在系统权限或角色授予语句上，它不把权限“复制”给被授者，而是赋予其独立的、可自主行使的授权能力。这个能力一旦授予，就与原始授权解耦——就像给你一把刻章机，你刻出的章是否有效，不取决于原厂是否还在营业。
所以当你执行 REVOKE CREATE SESSION FROM A，只是收走 A 自己的登录能力，而 A 之前用这台“刻章机”盖给 B 的章（即 GRANT CREATE SESSION TO B），Oracle 认为那是 B 和数据库之间直接建立的契约，与 A 无关。
级联回收只适用于 WITH GRANT OPTION 的对象权限
对象权限（如 SELECT ON hr.employees）走的是另一套逻辑：WITH GRANT OPTION 表示“你代我授权”，回收时 Oracle 默认认为你是代理方，必须一并清理下游链路。这是设计上的明确区分：
-
WITH ADMIN OPTION→ 系统权限 / 角色 → 回收无级联 -
WITH GRANT OPTION→ 对象权限 → 回收带级联（加CASCADE CONSTRAINTS可显式控制，但默认已生效）
混淆这两者是 ORA-01031 排查中最常见的误判点：看到 B 失去了某对象权限，就去查 A 是否被 revoke，结果发现 A 的权限还在——其实问题出在 A 当初根本没加 WITH GRANT OPTION，B 的权限压根不是 A 转授的，而是从别处来的。
DBA_ROLE_PRIVS 不显示“谁授的”，只存当前状态
想靠查视图还原授权路径？DBA_ROLE_PRIVS 和 DBA_SYS_PRIVS 都只记录“谁有啥”，不存“谁给的”。即使你启用了统一审计（UNIFIED_AUDIT_TRAIL），也得提前配置策略捕获 GRANT 操作，否则操作一过，源头就不可追溯。
这意味着：如果 A 被 revoke 后，B 还能连库、能建表、能查 DBA 视图，那大概率是因为
- B 自己也被直接授予了
CREATE SESSION或SELECT_CATALOG_ROLE - B 所属的某个角色（比如
APP_DEVELOPER）被别人用WITH ADMIN OPTION授予过，且该角色未被回收 - 数据库启用了 OS 认证或外部角色映射，权限来自系统层而非 SQL 授予链
真正要防的不是“回收不级联”，而是“转授失控”
ADMIN OPTION 的危险性不在回收难，而在扩散快且难追踪。一个被授予 GRANT ANY PRIVILEGE WITH ADMIN OPTION 的用户，理论上可以给自己加任何权限，也能绕过最小权限原则批量放权。这类账号一旦泄露或误操作，影响远超单个权限丢失。
所以生产环境应严格限制 WITH ADMIN OPTION 的使用范围，尤其避免授予非 DBA 用户以下权限：
GRANT ANY PRIVILEGEGRANT ANY ROLE-
UNLIMITED TABLESPACE（哪怕带ADMIN OPTION，也意味着配额可被无限转授）
真正容易被忽略的点是：权限回收后，你以为业务断了，其实可能只是某个中间角色没被同步清理——因为它的上级角色仍持有 WITH ADMIN OPTION，悄悄重建了授权链。
