pam是linux认证体系的底层调度中枢，通过auth（验身份）、account（查权限）、password（管改密）、session（控会话）四类模块分工协作，结合required/requisite等控制标志精准调度执行逻辑。
Linux 用户权限管理中，PAM 不是附加功能，而是整个认证体系的底层调度中枢。它不直接决定“谁有权限”，而是定义“怎样验证权限”——把密码校验、账户状态检查、会话初始化等动作拆解成可组合的模块，再通过配置文件精准控制执行逻辑。真正管住用户行为的，不是 sudoers 或 group 设置本身，而是 PAM 如何响应这些请求。
PAM 四类模块各司其职
每个 PAM 配置行都属于以下一种类型，顺序和职责不可混淆：
- auth：确认“你是谁”。例如验证密码、调用指纹或 OTP 模块。失败时用户无法通过身份核验。
- account：判断“你现在能不能用”。检查账户是否过期、是否在允许登录时间段、是否被锁定，不涉及密码。
- password：约束“你怎么改密码”。控制新密码长度、历史记录、字符类型等，仅在 passwd 或类似命令中触发。
- session：管理“你登录后发生了什么”。比如设置环境变量、记录审计日志、挂载家目录、限制资源（通过 pam_limits.so）。
/etc/pam.d/ 下的配置文件分工明确
不同服务走不同认证路径，不能只改 common-* 就以为全局生效：
-
/etc/pam.d/su控制直接运行 su 命令的行为（比如是否允许 wheel 组切换 root）。 -
/etc/pam.d/sudo管理 sudo 执行时的附加认证，例如加auth required pam_deny.so可禁止 sudo 后再 su。 -
/etc/pam.d/sshd决定 SSH 登录阶段的策略，如是否启用公钥+密码双因子。 -
/etc/pam.d/common-auth等“公共文件”被多个服务@include引用，适合统一部署基础策略（如密码强度），但需注意修改后影响范围。
控制标志决定模块成败如何影响整体结果
同一类模块中，控制标志像交通信号灯一样协调流程：
-
required：该模块必须成功；失败不立即终止，但最终认证一定拒绝。 -
requisite：一票否决，失败立刻中断，后续模块不再执行。 -
sufficient：一旦成功，跳过同类型剩余模块；失败则忽略，继续执行。 -
optional：无论成败，都不改变整体结果，常用于日志或调试。
安全加固的关键实操点
绕过权限管控常因路径遗漏，而非策略不严：
- 禁用
sudo su -不是删掉 sudo 权限，而是在/etc/pam.d/sudo中插入 account 规则，拒绝非白名单用户调用 shell 切换。 - 防止暴力破解，应在 auth 段加入
pam_faildelay.so delay=3000000（延迟3秒），并在 password 段启用pam_pwquality.so retry=3 minlen=10。 - 检查
/etc/pam.d/other是否为默认 deny 配置，避免未显式配置的服务被意外放行。 - 修改前务必备份原文件；测试新配置时，保留一个 root 会话，避免锁死自己。
