Oracle创建同义词是否自动授予底层表SELECT权限？开发与生产环境行为差异原因

创建同义词是否会自动授予底层表访问权限 #

答案是完全不会。
同义词本身只是一个对象路径的别名指针，不承载任何权限相关的逻辑：

• 你在schema1下创建属于schema2的私有同义词，本质是存了一条“当schema2查询对象名为test时，实际指向schema1下的test表”的路径映射，全程没有任何权限授予的动作
• Oracle在执行查询时，会先通过同义词解析出底层表的真实路径，再回到表所属的schema1，校验当前执行SQL的账号是否拥有该表对应的SELECT/INSERT等实际对象权限
• 整套权限校验逻辑和不使用同义词、直接写select * from schema1.test的规则完全一致，不会因为存在同义词就跳过权限检查，更不会在建同义词的环节自动把底层表的权限授予同义词所属的schema2。

开发与生产环境访问行为差异的根因 #

两边表现不一致，本质是两个环境的权限配置存在差异，常见的具体场景包括：

• 开发环境给schema2配置了过宽的系统权限：比如为了省事直接给schema2授予了SELECT ANY TABLE这类可以跨Schema查询任意表的系统权限，或是把schema2关联到了带DBA、SELECT ANY TABLE权限的角色上。这类高权限在生产环境一般会严格管控，不会开放给普通业务Schema。
• 开发环境存在兜底授权逻辑：比如过往运维操作中，给所有业务Schema批量授予了普通表的全库SELECT权限，或是创建了指向schema1.test的公共同义词，查询请求走了公共授权的校验路径，根本没有触发你手动创建的私有同义词对应的权限校验流程。
• 开发环节的操作身份存在偏差：开发人员连接开发库时实际用的是schema1本身的账号，并不是schema2，执行查询时访问的是自己Schema下的同名表，没有走到跨Schema访问的逻辑，自然不会触发权限不足的报错。
• 开发环境的schema2被配置了特殊特权：比如开启了字典查询特权、或是本身就是具备全库访问能力的管理员账号，不受普通对象权限的限制；而生产环境严格遵循最小权限原则，仅给schema2授予了明确需要的对象权限，没有配置这类越级访问的授权。

快速排查方法：在权限异常的环境下，以schema2身份执行select * from session_privs;查看当前会话拥有的全部系统权限，执行select * from table_privs where grantee='SCHEMA2';查看schema2被授予的所有对象权限，就能快速定位和开发环境的配置差异。

内容的提问来源于stack exchange，提问作者swathi manda