查表权限必须加owner条件，否则混查同名表风险高；需区分对象权限（dba_tab_privs）与系统权限（dba_sys_privs），并结合角色视图递归验证，权限不足时降级使用all_tab_privs或user_tab_privs。
查某张表谁有权限，必须带 owner 条件
直接 select * from dba_tab_privs where table_name = 'emp' 会混入 scott.emp、hr.emp、test.emp 等所有同名表的记录，误判风险极高。真正要定位“谁对 scott 用户下的 emp 表授了什么权”，必须显式加 owner = 'scott'。
常见错误：把用户名当 OWNER（比如用户叫 app_user，但它的表 OWNER 是 APP_USER；若建表时用了双引号，OWNER 可能是小写，需原样匹配）。
- OWNER 和 TABLE_NAME 默认大写，除非建对象时加了双引号
- GRANTEE 可能是用户、角色或
PUBLIC——查到PUBLIC要立刻标记为高危 - GRANTABLE = 'YES' 表示该权限可再转授，等于开了二级授权口子
排查越权时别只盯 GRANTEE，得反向查被授权对象
越权访问常不是因为用户被多授了权限，而是某个敏感表（比如 HR.SALARY）被无意授予了太多人。这时用 OWNER = 'HR' AND TABLE_NAME = 'SALARY' 去查 DBA_TAB_PRIVS，比遍历每个用户更高效。
注意：DBA_TAB_PRIVS 不包含角色继承来的权限，所以看到某用户没记录，不代表他没权限——可能通过角色获得，得补查 DBA_ROLE_PRIVS 和 ROLE_TAB_PRIVS。
- 若 GRANTEE 是角色名（如
'APP_ROLE'），必须递归查该角色成员，不能停在这一步 - 视图权限也走这张表，但基表权限缺失会导致查询失败，需用
ALL_VIEWS看定义再逐层验 -
REFERENCES权限容易被忽略，但它允许建外键，可能间接暴露主键或触发级联操作
权限为空≠没授权，先确认你有没有查的权限
执行 SELECT * FROM DBA_TAB_PRIVS 报 ORA-00942: table or view does not exist，大概率不是视图不存在，而是当前用户缺 SELECT ANY DICTIONARY 或 SELECT_CATALOG_ROLE。
此时降级用 ALL_TAB_PRIVS（只显示你有 SELECT 权限的对象）或 USER_TAB_PRIVS（仅自己拥有的直接权限），但结果集大幅缩水，做风险评估时极易漏掉真实越权点。
-
ALL_TAB_PRIVS不包含你无访问权的对象，哪怕别人已授你SELECT ANY TABLE - 普通用户默认查不到
DBA_TAB_PRIVS，连ALL_TAB_PRIVS都可能受限，得找 DBA 代查 - 查不到预期记录，优先核对三件事：权限是否足够、OWNER 是否写对、用户名大小写是否匹配
对象权限和系统权限必须分开查，混查必漏
DBA_TAB_PRIVS 只存对象级权限（如对 SCOTT.EMP 的 SELECT），系统级权限（如 CREATE TABLE、DROP ANY TABLE）全在 DBA_SYS_PRIVS 里。有人想“一网打尽”，只查一张表，结果一半权限根本看不见。
典型漏检场景：用户被授了 DBA 角色——DBA_TAB_PRIVS 里只有它被直接授的几张表权限，而 CREATE SESSION、ALTER SYSTEM 这类高危能力全在 DBA_SYS_PRIVS 里。
- 查系统权限用
DBA_SYS_PRIVS WHERE GRANTEE = 'USERNAME' - 查角色所含系统权限，得去
ROLE_SYS_PRIVS -
DBA_TAB_PRIVS中的GRANTOR = 'SYS'不一定代表 DBA 手动授的，很可能是系统角色隐式授予，得结合ROLE_TAB_PRIVS判断
实际排查时，最麻烦的永远不是语句怎么写，而是权限链路太深：对象权限 → 角色 → 角色的系统权限 → 角色嵌套 → 细粒度策略拦截。每层都得手动验证，没法靠单条 SQL 自动展开。
