oracle无法直接禁用password命令，因其是客户端工具内置命令、不经过sql解析器，dba无法通过权限或触发器拦截；必须回收alter user权限并绑定严格profile（如password_life_time 365、password_reuse_time unlimited）组合限制。
Oracle 默认允许普通用户用 PASSWORD 命令修改自己密码，无法直接禁用该行为；必须通过权限回收 + profile 限制组合实现“事实禁止”。
为什么不能直接禁止 PASSWORD 命令
Oracle 没有类似 DISALLOW PASSWORD CHANGE 的开关。只要用户能建立会话（即拥有 CREATE SESSION），就能执行 PASSWORD —— 这是客户端工具（如 SQL*Plus、SQL Developer）内置的命令，不走 SQL 解析器，DBA 无法用审计或触发器拦截。
常见误解是回收 ALTER USER 权限就能阻止，但错：普通用户改自己密码根本不需要该权限。
真正有效的限制路径：回收权限 + 锁死 profile
要让用户“想改也改不了”，需同时满足两个条件：
- 回收用户对自身账户的
ALTER USER权限（虽不影响PASSWORD，但堵住其他绕过方式） - 将用户绑定到一个严格限制的
PROFILE，且该 profile 中设置PASSWORD_REUSE_TIME和PASSWORD_REUSE_MAX为极值，再配合PASSWORD_LIFE_TIME强制长周期
例如：
CREATE PROFILE no_self_change LIMIT PASSWORD_LIFE_TIME 365 PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1/24;
然后执行：
ALTER USER scott PROFILE no_self_change;
注意：PASSWORD_REUSE_TIME UNLIMITED 表示“永远不准重用旧密码”，PASSWORD_LIFE_TIME 365 表示“一年内不准主动改”，两者叠加后，用户即使输对旧密码执行 PASSWORD，也会立刻收到 ORA-28007: the password cannot be reused 或 ORA-28002: the password will expire within 7 days 类错误，实际无法完成修改。
容易踩的坑：profile 绑定失效 & 客户端缓存
以下情况会导致限制“看似生效实则无效”：
- 用户实际使用的 profile 不是刚改的那个 —— 查
SELECT profile FROM dba_users WHERE username = 'SCOTT'确认 - 用户在 PL/SQL Developer 或 SQL Developer 中已保持连接，
PASSWORD命令仍走旧 session 上下文，需彻底断开重连才触发新 profile 策略 - 误设
PASSWORD_GRACE_TIME过长（如设为 90 天），用户会在过期前仍可登录并改密码，削弱限制效果 - 用
ALTER PROFILE DEFAULT修改，但用户明确指定了别的 profile（如APP_PROFILE），DEFAULT 的改动完全不生效
终极防线：只给最小权限 + 定期审计
如果业务上真不允许用户碰密码（比如统一由 IAM 系统托管），就不要给用户本地数据库账号，改用外部身份源（如 OIDC、LDAP）。若必须用本地账号，则：
- 创建用户时显式指定受限 profile：
CREATE USER scott IDENTIFIED BY "x" PROFILE no_self_change; - 不授予
ALTER USER，也不给GRANT ANY PRIVILEGE类高危权限 - 定期查
dba_audit_trail中ACTION_NAME = 'PASSWORD CHANGE'的记录（需提前开启审计：AUDIT ALTER USER）
真正的难点不在技术配置，而在于 profile 的生命周期管理——一旦 DBA 手动执行过 ALTER USER ... IDENTIFIED BY，就等于绕过了所有 profile 限制。所以策略落地后，必须同步收紧 DBA 操作规范。
