CONNECT角色不可修改，因其含7项固定系统权限，修改会导致升级失败、工具报错及应用异常；应创建自定义角色实现最小权限控制。
connect 角色在 oracle 11g 中不是“只读连接权限”，而是实际包含 7 项系统权限（如 create session、create table、create view 等），直接修改它会影响所有依赖该角色的用户——这不是安全加固，而是破坏性操作。
CONNECT 角色被修改后，新创建用户若仍用 GRANT CONNECT TO user1，会获得你改过的权限集；已有用户不受影响（角色权限是授予时快照，不随角色定义动态更新），但重置角色或 SET ROLE ALL 后可能意外丢失/获得权限。
CONNECT 角色不该被修改
- Oracle 明确将
CONNECT定义为预置角色，其权限集在版本间有兼容性保证 - 手动
REVOKE CREATE TABLE FROM CONNECT或GRANT SELECT ANY DICTIONARY TO CONNECT会导致：- 数据库升级或补丁安装失败（校验脚本检测角色完整性）
- OEM、Data Pump、RMAN 等工具内部调用依赖
CONNECT的默认行为，静默报错如ORA-00942 - 应用部署脚本假设
CONNECT含CREATE SYNONYM，缺失则对象解析失败
真正需要最小化权限时，不要碰 CONNECT
- 创建自定义角色，例如
r_app_login，只授CREATE SESSION和必要对象权限 - 对临时用户或 API 账号，直接
GRANT CREATE SESSION TO user_api，不走角色层 - 若必须复用角色机制，用
ALTER USER user_api DEFAULT ROLE NONE+ 按需SET ROLE r_app_read控制激活态
CONNECT 权限变更无法回滚到出厂状态
Oracle 不提供恢复预置角色的命令。一旦执行了 REVOKE 或 GRANT，只能人工比对文档重新补全全部 7 项权限，漏一项（比如 ALTER SESSION）就会导致应用连接池初始化失败——这种问题往往出现在压测环境，日志里只显示 “connection reset”，根本不会提示缺权限。
真正要控制权限粒度，靠的是隔离：角色分层建（r_session_only、r_schema_owner）、权限直授关键用户、存储过程里绝不依赖角色生效——这些动作比动 CONNECT 安全得多，也容易审计。
