在 Oracle 数据库中创建角色时，必须明确指定 IDENTIFIED BY 或 NOT IDENTIFIED；未认证角色后续无法再补加密码，只能删除后重建；批量分配权限时，建议通过 DBA_OBJECTS 动态生成 GRANT 语句，而不是直接授予 SELECT ANY TABLE；WITH ADMIN OPTION 存在权限扩散与失控风险；角色嵌套超过 2 层时，可能触发 ORA-01927；角色权限调整后，通常需要重新连接或执行 SET ROLE 才会生效。
CREATE ROLE 语句必须显式指定 IDENTIFIED BY 或 NOT IDENTIFIED
在 Oracle 中创建角色时，使用 CREATE ROLE 如果不特别说明，默认得到的是“非认证角色”，也就是 NOT IDENTIFIED。这类角色不能设置密码保护，也无法通过外部身份验证方式启用。也就是说，如果你后续希望使用 SET ROLE role_name IDENTIFIED BY ... 的方式激活角色，那么在创建该角色时就必须显式写上 IDENTIFIED BY 子句。
很多人在创建 Oracle 角色时常见的错误，就是漏掉这个子句，结果导致后面无法通过密码切换角色：
CREATE ROLE app_reader; -- ✅ 非认证角色，可直接 GRANT/REVOKE
CREATE ROLE app_reader IDENTIFIED BY "R3ad@2026"; -- ✅ 支持密码切换
如果角色已经创建为未认证角色，后期不能通过 ALTER 再补充密码，只能先 DROP ROLE，然后重新创建角色。
批量授对象权限：别依赖 SELECT ANY TABLE，用 DBA_OBJECTS 动态生成 GRANT
如果要给某个角色批量授予指定 schema 下所有表的 SELECT 权限，更安全、更可控的方式并不是直接授予 SELECT ANY TABLE 这种高权限，而是查询 DBA_OBJECTS，动态生成精确的授权语句。
建议在 SYS 用户或具备 SELECT_CATALOG_ROLE 权限的账号下执行：
SELECT 'GRANT SELECT ON ' || owner || '.' || object_name || ' TO app_reader;' FROM dba_objects WHERE owner = 'HR' AND object_type = 'TABLE';
- 查询结果会生成多条类似
GRANT SELECT ON hr.employees TO app_reader;的 Oracle 授权语句，复制后执行即可 - 注意：
owner一般需要使用大写（例如'HR'），否则可能出现匹配不完整的问题 - 如果目标 schema 中还包含视图、序列等对象，可额外增加
OR object_type IN ('VIEW', 'SEQUENCE')
GRANT 系统权限时 WITH ADMIN OPTION 的风险要盯住
在 Oracle 中给角色授予系统权限（例如 CREATE SESSION、CREATE TABLE）时，如果附带 WITH ADMIN OPTION，就表示该角色持有者还可以把这些权限继续授予其他用户或角色。这会让权限传递脱离 DBA 的集中控制，带来明显的安全风险。
典型的误用场景包括：
GRANT CREATE TABLE TO app_dev WITH ADMIN OPTION;→ app_dev 用户可自行执行GRANT CREATE TABLE TO attacker_user;- 一旦角色被异常账号或恶意用户获取，整条权限传播链将很难追踪和收敛
- 在生产环境中，除非确实存在明确的 delegation 需求（例如中间件部署账号），否则通常不建议添加
WITH ADMIN OPTION
如果想排查当前哪些账号或角色具备转授权能力，可执行：SELECT * FROM dba_sys_privs WHERE admin_option = 'YES';
角色嵌套深度超过 2 层可能触发 ORA-01927
在 Oracle 数据库里，角色支持链式授权：例如角色 A 可以授予角色 B，角色 B 还可以继续授予角色 C。但这里有一个很容易被忽视的限制——角色嵌套层级默认最多只有 2 层。也就是说，A→B→C 这种关系通常可用，但如果继续扩展成 A→B→C→D，就很可能出现问题。超过该层级后，常见表现要么是直接报错：ORA-01927: cannot revoke privileges you did not grant，要么是用户登录后发现相关权限并未真正生效。
可按以下思路进行排查：
- 查看当前会话中所有已生效角色：
SELECT * FROM session_roles; - 查看某个角色下又包含了哪些角色：
SELECT granted_role FROM dba_role_privs WHERE grantee = 'APP_READER'; - 尽量避免三层及以上的角色嵌套；如果权限模型较复杂，优先考虑合并到单一角色中，而不是依赖多层链式授权
还有一个特别容易被忽略的点是：角色继承和权限状态通常会在用户会话建立时固化。也就是说，修改完角色权限后，已有数据库连接不会自动刷新，必须让用户重新 CONNECT，或者手动执行 SET ROLE，新的权限配置才会正式生效。
