SELECT ANY TABLE 是全局系统权限，授予后用户可无条件查询所有普通表，属过度授权；应改用角色+对象权限的最小权限方案。
SELECT ANY TABLE 是全局权限，不是表级只读授权
直接授予 select any table 给用户，等同于赋予其对当前数据库中所有现有及未来新建的普通表（不含系统表，除非额外授权）无条件 select 权限。这不是“创建只读用户”的合理方式，而是过度授权——它绕过了对象所有权边界，且无法限制视图、物化视图或特定 schema 下的表访问粒度。
- 该权限属于系统权限（
SYSTEM级），需DBA或具备GRANT ANY PRIVILEGE的用户执行 - 授予后，用户可查
SCOTT.EMP、HR.DEPARTMENTS，甚至其他业务 schema 中未显式授权的表 - 撤销困难：不能按 schema 或表批量回收，只能整权收回或逐个 revoke 对象权限
真正可控的只读用户应基于对象权限 + 角色组合
生产环境推荐用最小权限原则：先建角色，再授对象权限，最后将角色赋给用户。这样既能限定 schema 范围，又便于后续增删表权限。
- 创建只读角色：
CREATE ROLE app_readonly; - 为角色授予指定 schema 下所有表的 SELECT 权限（需在该 schema 下执行或用
GRANT SELECT ON schema.table TO role循环）：SELECT 'GRANT SELECT ON ' || owner || '.' || table_name || ' TO app_readonly;' FROM dba_tables WHERE owner IN ('APP_SCHEMA', 'CONFIG_SCHEMA'); - 授予角色给用户：
GRANT app_readonly TO readonly_user; - 禁用用户登录以外的操作：
ALTER USER readonly_user PASSWORD EXPIRE;+ALTER USER readonly_user ACCOUNT LOCK;（若仅用于连接应用，不需交互登录）
用 WITH GRANT OPTION 要特别小心
如果误在授 SELECT ANY TABLE 时加 WITH ADMIN OPTION，被授权用户就能把该权限再转授他人，甚至授予 DBA 权限持有者都难以快速追踪的二级权限链。
-
SELECT ANY TABLE本身不支持WITH GRANT OPTION（语法报错ORA-01931: cannot grant SELECT ANY TABLE with GRANT OPTION），但类似权限如SELECT_CATALOG_ROLE可被带选项授予，风险更高 - 对象级
GRANT SELECT ON t TO u WITH GRANT OPTION允许 u 再授给 v，一旦 u 账户泄露或误操作，权限扩散不可控 - 审计建议：定期查
DBA_TAB_PRIVS和DBA_SYS_PRIVS，过滤GRANTABLE = 'YES'的记录
注意视图、同义词和数据字典访问的隐含行为
即使没授 SELECT ANY TABLE，用户仍可能通过其他路径读到敏感数据——这不是漏洞，而是 Oracle 权限模型的设计特性。
- 只要用户有
SELECT权限的视图，且视图定义里引用了其他 schema 的表，Oracle 默认启用“视图合并”和“权限检查下推”，不会因底层表无权限而报错（前提是视图创建者有相应权限且未用WITH CHECK OPTION） - 公共同义词（
CREATE PUBLIC SYNONYM）指向某张表时，用户只需对该同义词有 SELECT 权限，即可访问原表——权限实际校验的是同义词指向的对象 -
SELECT_CATALOG_ROLE这类预定义角色会间接开放DBA_*、ALL_*视图，从而暴露元数据（如表结构、索引名），不属于“纯数据只读”范畴
真正安全的只读方案必须结合 schema 边界、对象粒度控制和持续审计；依赖单一系统权限既难维护，也违背最小权限原则。尤其当数据库含多个业务模块时，一个 SELECT ANY TABLE 就可能让财务模块数据意外暴露给营销系统账号。
