必须显式回收ALTER USER系统权限才能禁止用户改密，因PROFILE仅控制密码策略（如有效期、复杂度），无法限制DDL语句执行；只要用户拥有ALTER USER权限，即可绕过PASSWORD_LIFE_TIME或密码验证函数直接执行ALTER USER ... IDENTIFIED BY。
不能靠 profile 限制，必须显式回收 alter user 权限。
为什么 PASSWORD_LIFE_TIME 或密码验证函数拦不住改密
用户执行 ALTER USER username IDENTIFIED BY newpass 是唯一合法改密途径，而这条语句的执行权限由系统权限控制，不是 profile 控制。即使你把 PASSWORD_LIFE_TIME 设为 UNLIMITED、或在 my_password_verify 函数里写 raise_application_error(-20001, 'not allowed')，也只会让改密失败并报 ORA-28003，但用户仍能反复发起该语句——只要他有 ALTER USER 权限。
常见误操作包括：
- 只修改 profile 却没查用户是否已被授予
ALTER USER - 以为禁用密码过期就等于禁止改密
- 在验证函数中抛错，误以为能阻断语法执行层
怎么确认用户是否真有改密能力
直接查系统权限表，别猜：
SELECT * FROM dba_sys_privs WHERE grantee = 'HFXF' AND privilege = 'ALTER USER';
如果返回结果非空，说明该用户（或其角色）拥有该权限。注意：
-
CONNECT角色默认不含ALTER USER，但很多 DBA 会额外GRANT ALTER USER TO hfxf - 若用户是通过代理连接（如
appuser[proxyuser]），还要查dba_proxies和proxyuser的权限 -
DBA角色用户天然具备此权限，profile 和 revoke 对其基本无效
真正有效的禁止方式：REVOKE ALTER USER
执行回收命令即可切断改密路径：
REVOKE ALTER USER FROM hfxf;
但要注意副作用：
- 该用户将无法修改任何用户的配额、默认表空间、临时表空间等（哪怕只是自己的）
- 如果业务逻辑依赖
ALTER USER ... QUOTA动态调优，需提前评估 - 代理用户场景下，还需确保
proxyuser本身没被授过ALTER USER，否则它仍可通过代理上下文执行ALTER USER appuser IDENTIFIED BY
更彻底的方案（需 Database Vault 许可）：用 realm 把 ALTER USER 操作纳入强制保护范围，连 DBA 都绕不过。
替代思路：禁用账户而非禁止改密
如果目标只是阻止登录，比“禁止改密”更直接有效的方式是锁定账户：
ALTER USER hfxf ACCOUNT LOCK;
这会让用户下次登录时立即报 ORA-28000: the account is locked，且不触发任何密码校验流程。相比权限回收，它：
- 不影响其他 DDL 权限（如建表、查视图）
- 不干扰代理连接或应用连接池行为
- 可随时
ACCOUNT UNLOCK恢复，无残留副作用
真正难处理的是既要保持账户可用、又要杜绝密码变更——这种需求几乎总意味着权限模型设计已偏离最小权限原则，得回头重审账号划分和连接方式。
