with admin option 的系统权限不支持级联收回，revoke 仅移除直接授权对象的权限，下游用户权限需手动查询 dba_sys_privs 和 dba_role_privs 并逐条回收。
WITH ADMIN OPTION 的系统权限不支持级联收回 —— 你无法通过 REVOKE 一条命令自动清除所有下游用户获得的权限。 这是 Oracle 的设计行为，不是 bug，也不是配置问题。
为什么 REVOKE 不会级联回收 WITH ADMIN OPTION 权限
Oracle 明确区分系统权限（如 CREATE SESSION、CREATE TABLE）和对象权限（如 SELECT ON scott.emp）的回收逻辑：
-
WITH ADMIN OPTION只用于系统权限或角色授权，它的语义是“可再授权”，但不绑定生命周期 - 当你执行
REVOKE CREATE SESSION FROM user_a，仅 user_a 失去该权限；user_b（由 user_a 授予）仍保留，且你无法通过任何隐式机制感知或批量清理 - 这与
WITH GRANT OPTION（仅用于对象权限）形成对比：后者在REVOKE时确实会级联删除下游权限
如何发现并清理“残留”的下游权限
没有自动级联，就得手动查 + 手动 revoke。关键是要定位谁从谁那里继承了权限：
- 查出哪些用户/角色拥有某系统权限（含来源）：
SELECT grantee, granted_role, admin_option, default_role<br>FROM dba_role_privs<br>WHERE granted_role IN ('CONNECT', 'RESOURCE')<br>UNION ALL<br>SELECT grantee, privilege, admin_option, NULL<br>FROM dba_sys_privs<br>WHERE privilege = 'CREATE SESSION'; - 重点看
ADMIN_OPTION = 'YES'的记录 —— 这些是潜在的“二级授权者” - 对每个二级授权者，再查他们授出去的权限：
SELECT * FROM dba_sys_privs WHERE grantee = 'USER_B';（替换为实际用户名） - 确认无误后，逐条
REVOKE，例如：REVOKE CREATE SESSION FROM user_b;
WITH ADMIN OPTION 被滥用的典型风险场景
这不是理论问题，真实运维中容易踩坑：
- DBA 给应用账号
APP_ADMIN加了WITH ADMIN OPTION，结果该账号误授DBA角色给测试用户，后续只REVOKE DBA FROM APP_ADMIN，测试用户仍保有 DBA 权限 - 交接或离职时，仅回收主账号权限，未审计下游，导致权限长期悬空
- 自动化脚本只处理
GRANTEE列表，忽略ADMIN_OPTION字段，漏掉二次授权链路
真正麻烦的从来不是“怎么加权限”，而是“加完之后，谁还拿着它”。WITH ADMIN OPTION 没有撤销钩子，也没有依赖视图能一键导出完整授权树 —— 它要求你主动维护权限拓扑意识，否则回收动作永远只是半截子工程。
