ALTER SESSION 权限无法被直接禁止，仅少数操作如SET TIME_ZONE、ENABLE PARALLEL DML、SET CONTAINER、SET EDITION受对应系统权限控制，其余如CURRENT_SCHEMA、NLS_LANGUAGE等不校验权限；有效限制需结合PROFILE、登录触发器及网络层拦截。
ALTER SESSION 权限无法被直接禁止，但可间接控制
Oracle 没有 DISALLOW ALTER SESSION 这类权限开关。ALTER SESSION 是用户连接后默认拥有的能力，只要能连上（即有 CREATE SESSION），就能执行大多数 ALTER SESSION 语句——比如 ALTER SESSION SET CURRENT_SCHEMA、SET NLS_DATE_FORMAT、SET ROLE 等。真正能被权限系统约束的，只有其中极少数子操作，比如修改时区或启用并行，它们依赖具体系统权限。
哪些 ALTER SESSION 操作实际受权限控制？
以下操作在执行时会触发权限校验，没对应权限就报 ORA-01031: insufficient privileges：
-
ALTER SESSION SET TIME_ZONE = '...→ 需要ALTER SESSION系统权限（注意：这个权限名和命令同名，但它是独立授予的） -
ALTER SESSION ENABLE PARALLEL DML→ 需要PARALLEL DML权限（不是角色，必须显式授） -
ALTER SESSION SET CONTAINER = ...（多租户场景）→ 必须在 CDB$ROOT 中拥有SET CONTAINER权限，且目标 PDB 已 open -
ALTER SESSION SET EDITION = ...→ 需要USE EDITION权限（授予 edition 对象）
而像 ALTER SESSION SET CURRENT_SCHEMA、ALTER SESSION SET NLS_LANGUAGE 这类，**不检查任何权限**，任何已登录用户都能用。
真正有效的限制手段：PROFILE + 触发器 + 应用层拦截
想让某用户“不能改会话行为”，靠权限模型硬拦是走不通的。可行路径是组合控制：
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
-
用 PROFILE 限制关键行为：设置
PASSWORD_LIFE_TIME UNLIMITED避免因密码过期被迫执行ALTER SESSION SET PASSWORD；禁用FAILED_LOGIN_ATTEMPTS防止锁账户后用户试图用ALTER SESSION绕过 -
登录触发器拦截高危会话设置：创建
AFTER LOGON ON DATABASE触发器，查V$SESSION中刚连上的用户，若发现其MODULE或CLIENT_INFO匹配预设规则（如来自某应用中间件），则EXECUTE IMMEDIATE 'ALTER SESSION SET ...'强制覆盖掉用户自设项（例如重置CURRENT_SCHEMA回白名单 schema） -
网络层/代理层过滤：在 Oracle Net 层（如 Oracle Connection Manager）或应用网关（如 HAProxy）拦截含
ALTER SESSION字样的 SQL 文本——但这会影响所有用户，且无法区分合法用途（如 JDBC 自动设置时区）
别指望 REVOKE ALTER SESSION FROM user —— 这条语句语法错误，Oracle 不支持撤销该动作本身。
最容易被忽略的细节：ALTER SESSION SET ROLE 的隐式依赖
用户执行 ALTER SESSION SET ROLE ALL 或指定角色时，Oracle 实际检查的是该用户是否已被授予那个角色（DBA_ROLE_PRIVS），以及角色中是否包含被 EXCEPT 排除的权限。如果你删了角色、或用 REVOKE ... FROM user 移除了角色，那 SET ROLE 就会失败——但这属于角色管理范畴，不是限制 ALTER SESSION 的手段。真正麻烦的是：即使你没给用户任何角色，他仍能执行 ALTER SESSION SET ROLE NONE，这是允许的。
