应查DBA_TAB_PRIVS中GRANTABLE='YES'的记录并向上追溯授权路径，因REVOKE不递归清除下游权限，需手动或脚本逐层回收，推荐用角色替代WITH GRANT OPTION以切断传播链。

对象权限被 WITH GRANT OPTION 误授后，如何快速定位源头

当用户a把表hr.employees的select权限带with grant option授予用户b，b又转授给c，c再授给d……这种链式传播会让权限失控。最直接的办法是查dba_tab_privs中所有含grantable='yes'的记录，并向上追溯授权路径。

执行以下语句可列出当前所有“可再授权”的对象权限链：

SELECT grantee, owner, table_name, privilege, grantable, grantor
FROM DBA_TAB_PRIVS
WHERE grantable = 'YES'
ORDER BY grantor, grantee;

注意：GRANTABLE字段为'YES'才表示该权限能被接收者继续授予他人；仅靠DBA_SYS_PRIVS查不到这类问题，它只管系统权限。

回收级联权限时，REVOKE 不会自动清除下游授权

Oracle 的 REVOKE 命令默认只断开直接授予关系，不会递归撤销下游用户已获得的权限。比如你对用户B执行REVOKE SELECT ON HR.EMPLOYEES FROM B，用户C、D仍保有该权限，且DBA_TAB_PRIVS里他们的记录依然存在。

必须手动逐层清理，或借助脚本生成回收语句：

• 先查出所有从B继承来的下游授权：用DBA_TAB_PRIVS连表查询grantee为B的记录，再查grantee为这些用户的记录
• 避免用REVOKE ... CASCADE——Oracle不支持这个语法，那是PostgreSQL的写法
• 生产环境建议先导出待回收清单：SELECT 'REVOKE ' || privilege || ' ON ' || owner || '.' || table_name || ' FROM ' || grantee || ';' FROM DBA_TAB_PRIVS WHERE grantor = 'B';

为什么不该长期依赖 WITH GRANT OPTION

这个选项本质是把权限管理权让渡给普通用户，等于在安全策略里开了个口子。真实运维中，90%以上的级联授权都不是业务必需，而是图省事临时加的。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

典型风险场景包括：

• 开发人员把测试库权限随意转授给外包同事，后者误删了视图依赖的基表
• 离职员工账户未及时清理，其曾授予他人的权限仍在生效
• 审计发现SCOTT用户对HR.SALARY_HISTORY有UPDATE且GRANTABLE='YES'，但没人记得当初为何开这个口

替代方案更稳妥：统一由DBA或自动化脚本按需授予权限，或改用角色——角色本身不带WITH GRANT OPTION传播能力，且便于批量回收。

用角色替代对象级级联授权的实际操作

把原本靠WITH GRANT OPTION扩散的权限，收编进一个受限角色，能彻底切断传播链。例如，原先用户B靠GRANT SELECT ON HR.EMPLOYEES TO B WITH GRANT OPTION把权限散出去，现在可以：

• 创建角色：CREATE ROLE hr_reader;
• 授予权限（不带WITH GRANT OPTION）：GRANT SELECT ON HR.EMPLOYEES TO hr_reader;
• 把角色给需要的人：GRANT hr_reader TO B, C, D;
• 后续只需REVOKE hr_reader FROM B，所有关联权限立即失效

关键点：角色不能被用户自行再授予他人，除非显式授予GRANT ANY ROLE——而这条系统权限本身就应该严格管控。

真正难处理的从来不是语法，而是权限链一旦形成，没人记得谁在哪一级点了“同意”。每次加WITH GRANT OPTION前，得问一句：这个用户真需要代替DBA做授权决策吗？