Oracle撤销角色不触发级联回收，因角色仅为权限容器，REVOKE仅解除角色与用户绑定，不扫描或撤销其包含的对象权限；需手动检查直接授权、角色链及PUBLIC授权。
Oracle里REVOKE ROLE不触发级联对象权限回收
因为Oracle的角色权限模型中，角色只是“权限容器”，它本身不参与对象依赖链的校验；撤销角色只切断角色到用户的绑定，不会主动扫描该角色曾授予的每一条对象权限并逐个撤回。
常见错误现象：给用户 u1 授予角色 r_data_reader，该角色包含 SELECT ON hr.employees；之后执行 REVOKE r_data_reader FROM u1，但 u1 仍能查 hr.employees —— 实际上是因 u1 还通过其他路径（比如直接授权、或另一个角色）持有该对象权限，而非级联失效没发生。
- Oracle 的
REVOKE role_name FROM user_name语义非常干净：只移除角色成员关系，不触碰任何底层对象权限定义 - 对象权限是否生效，取决于“当前会话能解析出的所有权限来源”（包括直接授权 + 所有已激活角色中的权限），撤销一个角色只是少了一条路径，不影响其他路径
- 没有类似 PostgreSQL 的
CASCADE机制去自动清理依赖该角色的对象级授权，这是设计选择，不是缺陷
怎么确认某用户实际拥有哪些对象权限
不能只看 DBA_ROLE_PRIVS，必须合并查询直接授权和角色间接授权的结果。
推荐组合查法：
SELECT grantee, owner, table_name, privilege, grantable FROM DBA_TAB_PRIVS WHERE grantee IN ( SELECT granted_role FROM DBA_ROLE_PRIVS WHERE grantee = 'U1' UNION ALL SELECT 'U1' FROM DUAL ) AND owner = 'HR' AND table_name = 'EMPLOYEES';
-
DBA_TAB_PRIVS包含直接授权 + 角色内含的对象权限（只要角色被授予了该用户） - 注意区分
GRANTABLE列：为YES表示该权限带WITH GRANT OPTION，可再转授 - 如果用户权限异常残留，优先检查是否还有其他角色或直接授权未清理
想真正清空用户对某张表的所有访问权，得手动扫三类来源
Oracle 不提供一键“断绝所有路径”的语法，必须分头处理。
- 查直接授权：
SELECT * FROM DBA_TAB_PRIVS WHERE grantee = 'U1' AND owner = 'HR' AND table_name = 'EMPLOYEES';→ 对每条结果执行REVOKE privilege ON owner.table_name FROM U1; - 查角色路径：
SELECT granted_role FROM DBA_ROLE_PRIVS WHERE grantee = 'U1';→ 检查每个角色是否含对该表的权限（用ROLE_TAB_PRIVS查）→ 必要时先REVOKE role FROM U1，或干脆REVOKE privilege FROM role - 查 PUBLIC 授权：
SELECT * FROM DBA_TAB_PRIVS WHERE grantee = 'PUBLIC' AND owner = 'HR' AND table_name = 'EMPLOYEES';→ 这类授权影响全局，需 DBA 级别决策是否收回
为什么MySQL/PostgreSQL行为看起来更“自动”，而Oracle不跟进
不是技术做不到，而是 Oracle 把“权限来源可追溯、变更可审计”放在首位；它坚持撤销操作必须显式对应到原始授予权限的主体（用户 or 角色），拒绝隐式推导依赖。
- PostgreSQL 的
REVOKE ... CASCADE是在权限依赖图上做一次局部遍历，Oracle 认为这会掩盖真实授权意图 - MySQL 根本不支持
CASCADE，它的对象权限撤销就是硬性断开，但也不处理角色链，所以表面“简单”，实则更易漏 - 真正容易被忽略的点：Oracle 中角色可以嵌套（
GRANT r2 TO r1），而REVOKE r1 FROM u1不会影响r2的状态，也不会触发r2内部权限的重新评估
