1. 项目概述：PAM 不是“密码验证模块”，而是 Linux 权限治理的神经中枢
很多人第一次听说 PAM，是在执行sudo命令输错密码时看到那句“Authentication failure”；或者在新建用户后发现su -失败，查日志却只看到一行模糊的pam_authenticate: Authentication failure。于是顺手搜“Linux PAM 是什么”，结果跳出一堆“PAM 是 Pluggable Authentication Modules 的缩写”“它提供认证、授权、会话管理、密码管理四大功能”——听起来很全，但看完还是不知道：为什么非得用它？不用行不行？改错一行配置就锁死 root，这玩意儿到底在系统里干了什么？
我从 2012 年开始在金融级 Linux 系统上做安全加固，亲手部署过超 300 台生产服务器的 PAM 策略，也踩过把/etc/pam.d/sshd改成空文件导致 SSH 连不上、只能物理机房重启的坑。今天这篇，不讲教科书定义，只说真实世界里 PAM 到底怎么运转：它不是贴在登录流程外的一层胶布，而是像人体的自主神经系统——你不需要主动控制呼吸和心跳，但所有服务（SSH、sudo、login、passwd、crond 甚至某些 GUI 应用）都默认接入它的反射弧。一个pam_faillock.so模块能让你 5 次输错密码后锁定账户 15 分钟；一个pam_umask.so能让所有新创建文件默认权限变成 0002；而pam_exec.so甚至可以调用 Python 脚本，在用户登录瞬间自动同步 LDAP 组策略到本地/etc/group。
关键词“Linux”“PAM”“体系结构”背后的真实需求，从来不是背诵概念，而是三件事：第一，看懂/etc/pam.d/下那些看似杂乱的配置文件，究竟如何协同控制一次登录的完整生命周期；第二，当业务要求“禁止 root 远程 SSH 登录但允许 sudo 切换”“所有运维账号必须启用双因素认证”“开发人员不能用su -切换到数据库用户”时，知道该动哪几行、为什么这么动；第三，出问题时能快速定位——是认证阶段失败？授权被拒？还是会话初始化卡在某个模块？而不是靠systemctl restart sshd碰运气。
这篇文章面向两类人：一类是刚通过useradd和passwd管理用户的初级运维，想搞懂“为什么改了/etc/shadow还是登不进系统”；另一类是正在设计企业级 Linux 安全基线的架构师，需要理解 PAM 如何与 SELinux、auditd、systemd-logind 协同构成纵深防御。全文不依赖任何发行版特有工具（比如 Ubuntu 的pam-auth-update），所有操作均基于 RHEL/CentOS 8+、Debian 11+、openSUSE Leap 15.4 等主流 LTS 系统通用机制，命令和配置可直接复制粘贴验证。接下来，我们一层层剥开 PAM 的真实肌理。
2. PAM 体系结构的本质：四条独立流水线 + 一套路由规则
PAM 的“体系结构”常被误读为“一堆模块堆在一起”。实际上，它的核心设计哲学是解耦与可组合。你可以把它想象成一座现代化化工厂的中央控制室：工厂有四条完全独立的生产线（Authentication、Account、Session、Password），每条线负责不同类型的加工任务；而控制室里有一套动态路由表（即/etc/pam.d/下的配置文件），决定某类产品（比如 SSH 登录请求）该走哪条线、经过哪些工位（模块）、按什么顺序、满足什么条件才放行。
2.1 四类模块类型：各司其职，绝不越界
| 模块类型 | 英文全称 | 核心职责 | 典型场景 | 关键约束 |
|---|---|---|---|---|
| auth | Authentication | 验证用户身份真实性 | 核对密码、检查指纹、调用 YubiKey API、查询 LDAP | 只读操作：不能修改用户状态，不能创建会话，不能改密码 |
| account | Account Management | 判断用户是否有权在此时此地访问此服务 | 检查账户是否过期、是否在允许登录时间段、是否属于特定组、是否达到最大并发会话数 | 无认证行为：不碰密码，不触发二次验证，纯策略判断 |
| session | Session Management | 管理用户会话的生命周期 | 登录成功后挂载家目录加密卷、记录登录时间到数据库、设置环境变量LANG=zh_CN.UTF-8、登出时清理临时文件 | 双向钩子：支持open_session和close_session两个入口点 |
| password | Password Management | 修改用户凭据（密码/密钥） | passwd命令更新/etc/shadow、强制密码复杂度、同步密码到 Active Directory | 仅在显式修改密码时触发：普通登录不走此链 |
提示：很多初学者混淆
auth和account。举个真实案例：某银行系统要求“所有员工账号必须每90天改一次密码”，这是password模块的事；但“外包人员禁止在周末登录核心交易系统”，这就是account模块的职责。如果错误地把时间限制写在auth链里，会导致用户连密码验证环节都进不去，日志里只显示“Authentication failure”，排查时会误判为密码错误。
2.2 控制标志（Control Flags）：决定模块成败的“一票否决权”与“弹性容错”
PAM 配置中形如[success=ok default=ignore]的字段，是整套体系最易错也最关键的逻辑开关。它不像编程语言的 if-else，而更像交通信号灯的相位控制器——每个模块执行后返回一个状态码（success/failure/ignore），控制标志则根据这个状态码决定后续动作。常见标志有四类：
required：当前模块必须成功，否则整个链最终返回失败；但即使失败，也会继续执行后续模块（用于日志审计或清理）。
实操心得：这是最常用也最危险的标志。曾有个客户在auth [required pam_deny.so]后面又加了一行auth [required pam_permit.so]，以为后者能覆盖前者。结果 PAM 严格按顺序执行：第一个模块返回 failure，整个 auth 链已注定失败；第二个模块虽成功，但无法翻盘。最终所有用户无法登录。requisite：当前模块一旦失败，立即终止整条链并返回失败，后续模块完全不执行。
典型用途：放在 auth 链开头做快速拦截，比如auth [requisite pam_time.so]限制登录时段，避免浪费资源去验证一个已被策略禁止的请求。sufficient：当前模块若成功，则整条链立即成功返回，后续模块全部跳过。
经典应用：双因素认证场景。auth [sufficient pam_google_authenticator.so]放在传统密码验证之后，用户扫完二维码即登录成功，无需再输密码；但如果扫码失败，流程自动回落到密码验证。optional：模块成功与否不影响整条链结果，仅用于收集信息或辅助功能。
例子：session [optional pam_exec.so /usr/local/bin/log_login.sh]，脚本执行失败不会导致会话创建失败，但能确保每次登录都被记录。
注意：
[success=ok default=ignore]这类高级语法本质是“跳转指令”。例如auth [success=2 default=ignore] pam_unix.so表示：若pam_unix.so认证成功，则跳过接下来 2 个模块；若失败，则忽略该模块结果继续执行。这种写法在多因素混合认证中极为灵活，但调试难度高，建议新手先掌握基础四标志。
2.3 配置文件层级：全局策略（/etc/pam.conf） vs 服务粒度（/etc/pam.d/*）
PAM 支持两种配置方式：单文件模式（/etc/pam.conf）和目录模式（/etc/pam.d/）。现代 Linux 发行版全部默认使用目录模式，因为其可维护性远超单文件。/etc/pam.d/下每个文件名对应一个服务名（service name），如sshd、sudo、login、cron。当某个程序调用 PAM 时，PAM 库会按以下优先级查找配置：
- 先找
/etc/pam.d/<service_name>（如sshd→/etc/pam.d/sshd）； - 若不存在，则找
/etc/pam.d/other（这是兜底文件，定义所有未显式配置的服务默认行为）； - 若
other也不存在，才回退到/etc/pam.conf（几乎不会用到）。
关键洞察在于：同一个模块可以在不同服务的配置中承担完全不同的角色。以pam_limits.so为例：
- 在
/etc/pam.d/login中，它通常放在session链，用于设置终端用户的ulimit（如maxlogins 3限制同一用户最多 3 个登录会话）； - 在
/etc/pam.d/sudo中，它可能放在auth链，配合pam_succeed_if.so实现“只有 dba 组成员才能用 sudo 启动 Oracle 实例”； - 而在
/etc/pam.d/crond中，它根本不会出现——因为 cron 作业不涉及交互式会话，无需设置 ulimit。
这种服务粒度的精准控制，正是 PAM 体系结构强大之处：你不必为整个系统设定一刀切的策略，而是像外科手术一样，对每个服务单独下刀。
3. 核心模块深度解析：从pam_unix.so到pam_faillock.so的实战拆解
PAM 模块库位于/lib/security/（x86_64 系统）或/lib64/security/（部分发行版），所有.so文件都是动态链接库。真正决定行为的是配置文件中的参数，而非模块本身。下面选取 5 个最常用、也最容易出错的核心模块，结合真实生产环境案例逐个击破。
3.1pam_unix.so：传统密码认证的基石，但绝非“万能钥匙”
这是所有 Linux 发行版默认启用的模块，负责读取/etc/passwd和/etc/shadow进行本地密码校验。其常用参数包括：
nullok：允许空密码用户通过认证（极度危险，生产环境严禁启用）；try_first_pass：尝试使用前一个auth模块提供的密码，避免重复输入（常与pam_pwquality.so配合）；use_authtok：强制使用前一个模块生成的密码（如pam_pwquality.so生成的新密码），跳过密码提示；sha512：指定密码哈希算法（RHEL 8+ 默认，比旧版 md5 更安全）；remember=5：记录最近 5 次密码，防止用户循环使用旧密码。
实操心得：
remember=5参数看似简单，但实际生效需满足两个前提：第一，/etc/security/opasswd文件必须存在且可写；第二，该参数必须出现在password链中，而非auth链。曾有个客户在auth链写了auth [required pam_unix.so remember=5]，结果毫无作用——因为auth链根本不处理密码修改逻辑。正确位置是/etc/pam.d/system-auth的password段。
3.2pam_faillock.so：账户锁定的黄金标准，但配置不当等于自废武功
这是 RHEL/CentOS 7+ 和 Debian 10+ 内置的防暴力破解模块，取代了老旧的pam_tally2.so。其工作原理是：在/var/run/faillock/目录下为每个用户创建独立计数文件（如alice），记录失败次数和时间戳。关键参数如下：
preauth：放在auth链开头，用于读取当前失败计数并判断是否已锁定；authfail：放在auth链末尾（在pam_unix.so之后），仅当认证失败时才增加计数；unlock_time=900：锁定 15 分钟（900 秒）后自动解锁；fail_interval=900：只统计最近 15 分钟内的失败尝试；deny=3：3 次失败即锁定；even_deny_root：连 root 账户也适用（慎用！必须确保有其他管理通道如 console 或带外管理）。
典型配置（以/etc/pam.d/system-auth为例）：
# 认证前检查是否已锁定 auth [default=ignore] pam_faillock.so preauth silent deny=3 unlock_time=900 fail_interval=900 # 认证失败时增加计数 auth [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900 # 认证成功时重置计数 auth [default=reset] pam_faillock.so注意事项：
pam_faillock.so的preauth和authfail必须成对出现，且顺序不能颠倒。如果把authfail放在preauth前面，会导致每次认证都先增加计数再检查，用户第一次输错就触发锁定。另外，unlock_time和fail_interval值应根据业务容忍度设定——金融系统可设为 300 秒（5 分钟），而内部测试环境可放宽至 3600 秒（1 小时）。
3.3pam_access.so：基于 IP/主机名/时间的细粒度访问控制
该模块读取/etc/security/access.conf文件，实现类似防火墙的访问策略。配置格式为：permission : users : origins。例如：
# 允许 root 仅从内网管理网段登录 + : root : 192.168.10.0/24 # 拒绝所有用户从公网 IP 登录 SSH - : ALL : 0.0.0.0/0 # 允许 dev 组成员在工作时间（8-18 点）登录 + : (dev) : ALL EXCEPT LOCAL : 0800-1800要使该策略生效，需在/etc/pam.d/sshd中添加：
account required pam_access.so accessfile=/etc/security/access.conf实操陷阱：
pam_access.so对origins字段的解析依赖于gethostbyaddr()系统调用。如果目标服务器 DNS 解析缓慢或不可靠，会导致登录延迟高达 30 秒以上。生产环境强烈建议在access.conf中优先使用 CIDR 网段（如192.168.1.0/24），避免使用主机名（如jump-server.internal），并在/etc/nsswitch.conf中将hosts行设为files dns，确保本地/etc/hosts优先查询。
3.4pam_umask.so：静默改变文件默认权限的隐形推手
Linux 新建文件默认权限由umask决定（通常为 0022，即文件 644，目录 755）。pam_umask.so可在用户登录时动态设置umask，且支持 per-user 配置。参数包括：
umask=0002：统一设置所有用户 umask 为 0002（文件 664，目录 775）；usergroups：为每个用户创建同名组，并设置 umask=0002，实现“同组用户可写”；silent：不向用户输出 umask 设置信息（避免干扰 shell 提示符）。
典型用法：在/etc/pam.d/common-session（Debian）或/etc/pam.d/system-auth（RHEL）中添加：
session optional pam_umask.so umask=0002关键细节：
pam_umask.so必须放在session链，且必须在pam_env.so之后。因为pam_env.so会加载/etc/environment和用户~/.pam_environment，其中可能包含UMASK变量。如果pam_umask.so在前，会被后续的环境变量覆盖。实测发现，RHEL 8 默认/etc/pam.d/system-auth中pam_umask.so位于pam_env.so之前，需手动调整顺序。
3.5pam_exec.so：PAM 体系的“任意门”，连接外部世界的桥梁
这是最强大的模块，允许在 PAM 流程中执行任意外部程序（Shell 脚本、Python、Go 二进制等）。参数type=open_session或type=close_session指定触发时机。例如，实现“用户首次登录时自动创建加密家目录”：
# /etc/pam.d/common-session session [default=ok] pam_exec.so type=open_session /usr/local/bin/init_encrypted_home.sh脚本/usr/local/bin/init_encrypted_home.sh内容：
#!/bin/bash # $1 是用户名，$2 是服务名（如 sshd） if [ ! -f "/home/$1/.first_login" ]; then # 创建 LUKS 加密卷 dd if=/dev/zero of="/home/$1/home.img" bs=1M count=1024 cryptsetup luksFormat --batch-mode "/home/$1/home.img" cryptsetup open "/home/$1/home.img" "$1-home" mkfs.ext4 "/dev/mapper/$1-home" mount "/dev/mapper/$1-home" "/home/$1" touch "/home/$1/.first_login" fi安全警告：
pam_exec.so执行的程序以root 权限运行！脚本中任何路径拼接漏洞（如rm -rf /home/$1）都可能导致灾难性后果。生产环境必须：1）脚本使用绝对路径且权限设为600（仅 root 可读写）；2）所有变量用双引号包裹（"$1"）；3）禁用setuid位；4）在脚本开头加入set -euo pipefail严格错误处理。我曾见过因未加引号导致rm -rf /home/$USER展开为rm -rf /home/的事故，整台服务器用户数据清零。
4. 实战：构建企业级 SSH 登录安全策略（含双因素+IP 白名单+会话审计）
现在我们将前面所有知识点整合，落地一个真实需求：某互联网公司要求所有运维人员通过 SSH 登录生产服务器时，必须满足——1）使用硬件令牌（YubiKey）进行双因素认证；2）仅允许从跳板机（IP 10.10.1.100）访问；3）登录后自动记录会话到审计服务器。以下是分步实现过程，每一步都附带原理说明和验证方法。
4.1 步骤一：安装并配置 YubiKey PAM 模块
首先安装libpam-yubico（RHEL/CentOS）或libpam-yubico（Debian/Ubuntu）：
# RHEL 8+ dnf install libpam-yubico ykclient ykpers # Debian 11+ apt-get install libpam-yubico yubikey-personalization获取 YubiKey 公钥（每个 Key 唯一）：
# 插入 YubiKey，运行 ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible # 输出类似：ccccccbabcljikvibhghbkhcbljikvibhghbkhc编辑/etc/yubikey_mappings，将用户与 Key ID 绑定：
alice:ccccccbabcljikvibhghbkhcbljikvibhghbkhc bob:ccccccbabcljikvibhghbkhcbljikvibhghbkhc4.2 步骤二：编写/etc/pam.d/sshd安全策略
备份原文件后，重写/etc/pam.d/sshd：
# 第1行：拒绝所有非跳板机 IP（account 链，不涉及认证） account [default=bad] pam_access.so accessfile=/etc/security/sshd_access.conf # 第2行：检查账户状态（是否过期、是否被禁用） account [default=ignore] pam_faillock.so preauth silent deny=3 unlock_time=900 account [default=die] pam_faillock.so authfail deny=3 unlock_time=900 account [default=reset] pam_faillock.so # 第3行：双因素认证（auth 链） auth [success=ok default=ignore] pam_yubico.so id=1 debug authfile=/etc/yubikey_mappings # 第4行：传统密码作为备选（sufficient 标志：成功则跳过后续） auth [sufficient] pam_unix.so try_first_pass nullok # 第5行：会话审计（session 链） session required pam_exec.so /usr/local/bin/audit_ssh_login.sh创建/etc/security/sshd_access.conf：
# 仅允许跳板机 + : ALL : 10.10.1.100 # 其他全部拒绝 - : ALL : ALL4.3 步骤三：编写会话审计脚本/usr/local/bin/audit_ssh_login.sh
#!/bin/bash # 参数说明：$1=用户名，$2=服务名（sshd），$3=远程IP，$4=TTY设备 # 获取真实客户端IP（处理 NAT 场景） CLIENT_IP=$(echo "$3" | awk -F',' '{print $1}') TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") LOG_ENTRY="[$TIMESTAMP] USER=$1 FROM=$CLIENT_IP SERVICE=$2 TTY=$4" # 发送到远程审计服务器（使用 nc 避免依赖复杂协议） echo "$LOG_ENTRY" | nc -w 2 audit-server.internal 514 2>/dev/null || \ echo "$LOG_ENTRY" >> /var/log/ssh_audit_local.log # 同时记录到本地 journal logger -t "pam-audit" "$LOG_ENTRY"赋予执行权限：
chmod 700 /usr/local/bin/audit_ssh_login.sh chown root:root /usr/local/bin/audit_ssh_login.sh4.4 步骤四：验证与故障排查全流程
验证步骤 1：检查 PAM 语法
# 使用 pamtester 工具（需安装） pamtester sshd alice authenticate # 输入密码，应返回 "Success" pamtester sshd alice authenticate # 再次输入错误密码，应返回 "Error"验证步骤 2：模拟跳板机访问
# 从 10.10.1.100 执行 ssh alice@prod-server.internal # 应提示 "YubiKey slot 2:"，插入 Key 后按按钮，再输密码验证步骤 3：验证 IP 白名单
# 从其他 IP 尝试 ssh alice@prod-server.internal # 应立即返回 "Permission denied (publickey,password)"，且 /var/log/secure 中有： # pam_access(sshd:account): access denied for user `alice' from `192.168.5.5'验证步骤 4：检查审计日志
# 查看本地日志 tail -f /var/log/ssh_audit_local.log # 应看到类似：[2023-10-05 14:22:33] USER=alice FROM=10.10.1.100 SERVICE=sshd TTY=pts/0 # 查看 journal 日志 journalctl -t "pam-audit" -n 10实操心得：PAM 配置修改后无需重启 sshd 服务！因为 PAM 是运行时加载的库，每次新连接都会重新读取配置。但务必在修改前确保有另一个 root 会话保持在线（如 console 或带外管理），以防配置错误导致所有 SSH 连接中断。我习惯在修改
/etc/pam.d/sshd前，先执行cp /etc/pam.d/sshd /etc/pam.d/sshd.bak.$(date +%s)，并用pamtester验证关键路径。
5. 常见问题与排查技巧实录：从日志定位到模块级调试
PAM 出问题时，症状往往模糊：“登不进去”“sudo 失败”“passwd 报错”。但只要掌握日志定位和模块调试方法，90% 的问题可在 5 分钟内解决。以下是我在上百次现场排障中总结的速查表。
5.1 日志分析：读懂/var/log/secure和journalctl的密语
PAM 日志默认输出到/var/log/secure（RHEL）或/var/log/auth.log（Debian）。关键字段解读：
| 日志片段 | 含义 | 排查方向 |
|---|---|---|
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.5 user=alice | pam_unix.so认证失败 | 检查/etc/shadow中 alice 密码哈希是否损坏；确认nullok未启用 |
pam_faillock(sshd:auth): user 'alice' does not exist in /var/run/faillock/ | 用户首次失败，计数文件未创建 | 确认pam_faillock.so authfail行存在且顺序正确 |
pam_access(sshd:account): access denied for user 'root' from '203.0.113.5' | pam_access.so拒绝访问 | 检查/etc/security/access.conf规则是否匹配，注意 IP 格式是否为 CIDR |
pam_exec(sshd:session): failed to exec /usr/local/bin/script.sh: Permission denied | pam_exec.so脚本无执行权限 | 运行ls -l /usr/local/bin/script.sh，确认权限为700且属主为 root |
提示：启用 PAM 调试日志（临时）：
# 在 /etc/pam.d/sshd 中某模块后加 debug 参数 auth [default=ignore] pam_yubico.so debug authfile=/etc/yubikey_mappings # 然后查看 /var/log/secure，会输出详细调用栈
5.2 模块级调试：用strace追踪 PAM 库调用
当日志不够明确时，用strace直接观察 PAM 库行为：
# 跟踪 sshd 进程的系统调用（需 root） strace -f -e trace=open,read,write,connect -p $(pgrep -f "sshd:") 2>&1 | grep -E "(pam|/etc/pam)"输出示例：
[pid 12345] open("/etc/pam.d/sshd", O_RDONLY) = 5 [pid 12345] read(5, "auth [success=ok default=ignore] pam_yubico.so ...\n", 8192) = 62 [pid 12345] open("/etc/yubikey_mappings", O_RDONLY) = 6这能清晰看到 PAM 是否正确加载了配置文件和映射文件。
5.3 经典问题速查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
修改/etc/pam.d/sshd后 SSH 完全无法连接 | auth链中required模块失败，且无备用路径 | 立即通过 console 登录，检查/etc/pam.d/sshd是否有语法错误（如漏写so后缀）；临时注释新增行，恢复默认配置 |
pam_faillock.so不生效 | preauth和authfail未成对出现；或/var/run/faillock/目录权限错误 | 运行ls -ld /var/run/faillock/，应为drwx------. 2 root root；确认两行参数中deny和unlock_time值一致 |
pam_exec.so脚本不执行 | 脚本路径错误；或session链中pam_exec.so位置太靠后（被pam_limits.so限制） | 在脚本开头加入echo "$(date): START" >> /tmp/exec_debug.log；检查/etc/security/limits.conf是否对用户设置了maxsyslog限制 |
| 双因素认证后仍提示输密码 | pam_yubico.so的sufficient标志缺失，导致流程继续执行pam_unix.so | 确认pam_yubico.so行末尾有sufficient，且位于pam_unix.so之前 |
用户登录后umask未生效 | pam_umask.so在pam_env.so之前；或用户~/.bashrc中覆盖了 umask | 运行grep umask ~/.bashrc，注释掉相关行；检查/etc/pam.d/system-auth中模块顺序 |
5.4 高级技巧：用pamtester构建自动化测试用例
为避免每次修改都手动测试，我编写了一个简单的测试脚本test_pam.sh：
#!/bin/bash # 测试用户 alice 的 SSH 认证流程 echo "=== Testing PAM auth for alice ===" pamtester sshd alice authenticate <<EOF yubikey_response_here password_here EOF # 测试账户策略 echo "=== Testing account restrictions ===" pamtester sshd alice account # 测试会话初始化 echo "=== Testing session setup ===" pamtester sshd alice open_session将此脚本加入 CI/CD 流程，在每次提交 PAM 配置前自动运行，可提前捕获 80% 的低级错误。
6. PAM 与现代 Linux 生态的协同演进：从 systemd-logind 到 SELinux
PAM 并非孤立存在，它与 Linux 内核、systemd、SELinux 等组件深度耦合。理解这种协同关系，才能设计出真正健壮的安全策略。
6.1 PAM 与 systemd-logind：会话生命周期的双重管理
systemd-logind是 systemd 的登录守护进程，负责管理用户会话（如图形界面、TTY、SSH）。它与 PAM 的关系是：PAM 负责“准入”，logind 负责“在场管理”。例如：
- 当用户通过 SSH 登录，PAM 的
session链执行pam_systemd.so，通知 logind 创建一个session-c1.scope； - logind 会为该会话分配 cgroup、设置资源限制（如
TasksMax=512），并监听IdleHint信号； - 如果 PAM
session链中pam_umask.so设置了umask=0002，logind 会将其注入到用户所有进程的Environment=UMASK=0002中。
关键配置：
/etc/systemd/logind.conf中的KillUserProcesses=yes与 PAMsession链的pam_systemd.so协同工作。前者确保用户登出时杀死所有进程，后者确保会话启动时正确注册。如果禁用pam_systemd.so，logind 将无法跟踪该会话，KillUserProcesses可能失效。
6.2 PAM 与 SELinux：策略执行的最后防线
SELinux 是内核级强制访问控制，而 PAM 是用户空间策略执行点。二者分工明确：SELinux 决定“进程能否访问某文件”，PAM 决定“用户能否启动该进程”。典型协同场景：
- 用户执行
sudo systemctl restart nginx：- PAM
auth链验证用户是否在wheel组且密码正确； - PAM
account链检查sudo是否在允许时间窗口内； sudo进程启动后，SELinux 策略（sudo_exec_t类型）决定它能否切换到system_r:system_t上下文；systemctl进程启动后，SELinux 再检查它能否读取/etc/nginx/nginx.conf（httpd_config_t类型）。
- PAM
实操经验：当遇到“PAM 认证成功但命令执行失败”时，先用
ausearch -m avc -ts recent检查 SELinux 拒绝日志。我曾处理过一个案例：pam_exec.so脚本调用curl访问内部 API，PAM 日志显示成功，但脚本始终超时。
