如何为Oracle用户授予只读查询权限

直接授予 SELECT ANY TABLE 权限是生产环境雷区，因其无法按 schema 或表名精细回收、绕过所有权边界、易暴露敏感元数据；正确做法是通过角色封装对象级 SELECT 权限，并严格管控登录与访问范围。

直接 GRANT SELECT ANY TABLE 是错的

这不是“快捷方式”，而是生产环境雷区。执行 GRANT SELECT ANY TABLE TO user_name 后，该用户能查所有 schema 下所有普通表（含未来新建的），且无法按 schema 或表名回收——只能整权收回或逐个 REVOKE，运维成本爆炸式上升。

更危险的是：它绕过对象所有权边界，连 DBA 都难快速定位权限来源；一旦误授，配合 SELECT_CATALOG_ROLE 或动态视图访问，可能意外暴露敏感元数据。

1. 该权限属系统级，需 DBA 或 GRANT ANY PRIVILEGE 才能执行
2. 不支持 WITH GRANT OPTION（语法报错 ORA-01931），但类似角色如 SELECT_CATALOG_ROLE 支持，风险更高
3. 撤销时必须用 REVOKE SELECT ANY TABLE FROM user_name，不能限定范围

正确做法：用角色封装对象级 SELECT 权限

核心是「先建角色、再授对象权限、最后赋角色」，把权限收口到角色里，后续增删表只需改角色，不影响用户本身。

例如要让 readonly_user 只能查 APP_SCHEMA 和 CONFIG_SCHEMA 下的表：

1. 创建角色：CREATE ROLE app_readonly;
2. 生成授权语句（在 DBA 身份下执行）：

   SELECT 'GRANT SELECT ON '|| owner ||'.'|| table_name ||' TO app_readonly;' FROM dba_tables WHERE owner IN ('APP_SCHEMA','CONFIG_SCHEMA');

3. 执行生成的每条 GRANT SELECT ON schema.table TO app_readonly;（注意不是 ANY TABLE）
4. 把角色给用户：GRANT app_readonly TO readonly_user;

别忘了基础登录权限和账号锁死

只读角色只管数据访问，用户连不上库等于白搭。新用户必须显式获得连接能力，且生产环境应禁用交互式登录：

1. GRANT CREATE SESSION TO readonly_user; —— 否则报错 ORA-01045
2. ALTER USER readonly_user ACCOUNT LOCK; —— 防止用 SQL*Plus 或其他客户端手动登录
3. ALTER USER readonly_user PASSWORD EXPIRE; —— 强制首次连接时改密（仅当需交互场景才启用）

如果应用通过连接池使用该账号，ACCOUNT LOCK 是必须项；否则账号可能被滥用。

视图、同义词、数据字典这些容易漏掉

对象级 GRANT SELECT 默认不覆盖视图、物化视图、同义词或数据字典表。若应用依赖它们，得单独处理：

1. 查 v$session 等动态性能视图？不要直接授 SELECT_CATALOG_ROLE（隐式权限太多），应建具体包装视图再授 SELECT
2. 同义词本身不继承底层权限，必须对原表/视图单独授权，再在只读用户下建同义词：CREATE SYNONYM htreader.ENTRY_HEAD FOR HEPSUSR.ENTRY_HEAD;
3. 查 dba_tables 这类数据字典表？极不推荐授 SELECT ANY DICTIONARY，应严格限制查询范围，或由应用层规避

真正可控的只读，从来不是靠“禁止写”，而是靠“只开读的门”——门开在哪、开多大、谁有钥匙，都得清清楚楚。