用户、组、Sudo 与 PAM

• 三个文件的关键字段
• 密码与权限模型
• 加固要点

/etc/passwd 每行 7 个字段：用户名、密码占位（x）、UID、GID、注释、家目录、默认 shell。密码实际存 /etc/shadow。/etc/shadow 每行 9 个字段：用户名、加密密码（或 !/! password 表示锁定）、最近修改天数、最小/最大修改间隔、警告天数、宽限期、失效期、保留。加密密码字段含 $type$salt$hash（$6$=SHA512）。/etc/group 每行 4 字段：组名、组密码（x）、GID、成员列表。加固要点：一是 /etc/passwd 权限 644、/etc/shadow 权限应为 000 或 600（仅 root），防止密码 hash 泄露；二是用 pwconv 把 passwd 密码同步到 shadow，禁用 passwd 文件中的明文密码；三是检查空密码、重复 UID、组文件错误；四是定期审计 /etc/passwd 中异常账号（UID 0、暂存账号）；五是强密码策略（PAM）、锁定弱口令、禁 root 远程登录。getent 可查整合后的用户信息。

核心是"字段理解 + 权限与审计"。shadow 权限收紧防哈希泄露，passwd 加固对空密码/重复 UID/UID 0 审计。

• Linux capabilities 机制
• 与 root 的替代关系
• 细粒度授权方案

Linux capabilities 把 root 的特权拆分为一个个能力（如 CAP_NET_ADMIN、CAP_SYS_ADMIN），进程可只获得所需能力，而非全部 root。相关方案比较：一是文件 capabilities（setcap），给特定二进制授能力，服务启动获得所需能力；二是容器 capabilities（Docker --cap-add/--cap-drop），容器进程默认降权，按需添加能力；三是 systemd 的 AmbientCapabilities/CapabilityBoundingSet，控制 unit 启动进程的能力；四是结合 seccomp/AppArmor/SELinux 做纵深防御。比较：capabilities 是"最小权限"的细粒度替代，比"全 root 或全非 root"更精确；但能力边界复杂，误配可能提权；需配合 seccomp（系统调用过滤）与 LSM（标签）才完整。rootless 方案（如 rootless 容器、用户命名空间）把 root 映射为普通用户，进一步减少特权。整体上"非 root 运行 + 最小能力 + seccomp + LSM"是现代加固方向。

核心是"最小权限替代 root"。capabilities 拆分特权，配合容器/ systemd/ seccomp/ LSM 实现细粒度授权，rootless 进一步降权。

• UID/GID 与用户名映射
• UID 复用风险
• 权限与审计

Linux 内核以 UID/GID（数字）识别用户/组，用户名只是 /etc/passwd 中的映射标签，文件权限、进程归属、访问控制都以 UID/GID 为准。因此 UID 复用（删除用户后新用户沿用同一 UID）会导致：新用户立即拥有旧用户所有文件、进程、cron 任务、脚本的权限，因为内核按 UID 判断归属；旧用户的残留数据（家目录、cron、临时文件、日志）被新用户接管，造成数据泄露与越权；审计（按用户名/UID）追踪混乱。安全影响：一是权限继承（新用户意外获得旧用户特权）；二是数据泄露（旧用户私有文件被新用户访问）；三是审计失效（无法区分同名 UID 的不同实体）。规避：删除用户时彻底清理（userdel -r 清理家目录与 cron，并避免 UID 复用），建立 UID 分配规范（系统账号低 UID、普通用户高 UID 段），避免 UID 复用。

核心是"内核按 UID 而非用户名授权"。UID 复用导致新用户继承旧用户权限与数据，需彻底清理并规范 UID 分配。

• PAM 模块链顺序
• 控制标志语义
• 认证结果组合

PAM 按 /etc/pam.d/ 中配置文件的顺序加载模块，模块链从文件顶部到底部执行。控制标志决定认证结果如何组合：required：必过，失败则整条认证失败，但会继续执行后续模块（不提前退出）；requisite：必过，失败则立即终止整条认证（不再执行后续模块）；sufficient：若通过则立即成功（跳过后续模块），若失败则忽略（不导致失败，继续）；optional：不决定性，仅当无其他模块时参考。optional 与 optional 组合、以及 required 的"继续执行"是区别关键。加载顺序影响：先执行的模块先验证，sufficient 在前可提前放行（如基于 pam_unix 成功后跳过 pam_sss），requisite 在前可快速失败（如 pam_faillock 计数）。正确配置顺序能优化流程与安全。

核心是"顺序 + 标志语义"。required 失败继续执行、requisite 失败立即停、sufficient 通过即放行跳过后续、optional 参考。

• PAM 架构与原理
• 常见模块作用
• 配置位置

PAM（Pluggable Authentication Modules）是可插拔认证框架，把认证从具体应用解耦：应用调用 PAM 接口，PAM 按 /etc/pam.d/<服务> 配置加载模块链，执行认证、账号、密码、会话管理。原理上分四类：auth（认证）、account（账号可用性）、password（密码更新）、session（会话管理）。常见模块：pam_unix 执行传统 Unix 认证（验证 /etc/shadow 密码）；pam_limits 设置会话资源限制（ulimit，对应 /etc/security/limits.conf）；pam_faillock 记录登录失败并锁定（防暴力破解，RHEL 8+ 替代 pam_tally2）；pam_sss/pam_ldap 对接集中身份；pam_env 设置环境变量；pam_pwquality 校验密码强度。工作原理：模块按顺序可配置 required/requisite/sufficient/optional，组合出认证结果。运维通过 /etc/pam.d/ 与 /etc/security/ 定制认证策略。

核心是"可插拔认证 + 模块链 + 四类管理"。auth/account/password/session 四类，pam_unix/limits/faillock 等各司其职。

• 三个命令的作用
• 密码老化字段
• 策略落地

passwd 修改用户密码（管理员可改他人、设锁定/过期）；chage 管理密码老化（change age）：查看/设置密码最长期限、最小期限、警告、失效、过期日期；pwconv 把 /etc/passwd 中的密码同步/迁移到 /etc/shadow（建立 shadow 文件，密码字段从 passwd 移入）。差异：passwd 改密码与锁定，chage 管老化策略，pwconv 迁移到 shadow。密码老化策略落地：一是通过 chage 设置 max days/min days/warning/inactive/expire（如 chage -M 90 -m 7 -W 7 user 90 天过期、7 天最小、7 天警告）；二是通过 /etc/login.defs 的 PASS_MAX_DAYS 等默认值；三是配合 PAM（pam_pwquality 强度、pam_lastlog）与 pam_faillock；四是定期审计 chage -l user 或 chage -l 检查过期。合规场景（等保）要求定期改密、密码复杂度、锁定策略。

核心是"命令分工 + 老化字段落地"。passwd 改密、chage 老化、pwconv 迁移 shadow，策略通过 login.defs/chage/PAM 落地。

• service account 与 system account
• systemd User= 配置
• 权限与安全

system account（系统账号）是通过 useradd -r 创建的账号，UID 在系统段（如 <1000），用于系统服务运行，无登录 shell、无家目录或受限，通常用于 systemd 服务（User= 属性访问不同系统用户）。service account（服务账号）通常指"用于运行某个服务的专用账号"，可以是系统账号或以服务名义创建的账号，拥有该服务所需的最小权限。在 systemd 单元中：User= 指定服务以哪个账号运行，Group= 指定组；使用专用账号（非 root）运行服务实现最小权限。差异：system account 是"系统级账号"（UID 低、无登录），service account 是"服务专用账号"（可能高 UID 或低 UID，按服务命名）。实践：每个服务用独立非 root 账号，User=/Group= 指定，配合 ProtectSystem 等加固；systemd 的 sysusers.d 可启动期创建这类账号。安全上避免用 root 运行服务，用专用账号 + 最小权限。

核心是"最小权限运行服务"。system account 是系统账号（低 UID 无登录），service account 是服务专用账号，systemd 用 User= 指定非 root 运行。

• su - 与 su 的环境差异
• wheel 组的 sudo 授权
• 安全实践

su（不带 -）切换用户但不切换环境（保留当前用户的环境变量、PATH、工作目录等），切换后环境可能是旧的；su -（带 -）以目标用户的登录 shell 登录，加载其完整登录环境（环境变量、PATH、家目录、umask），更接近重新登录。区别核心：su - 是 login shell，su 是 non-login shell，环境不同。wheel 组：在 RHEL 系中，wheel 组默认允许 sudo（sudoers 中 %wheel ALL=(ALL) ALL），只有 wheel 组成员才能 sudo 提权，是"管理员组"的工程约定。工程意义：把管理员加入 wheel 组即可获得 sudo 权限，同时避免把所有用户加入 sudoers；配合 NOPASSWD/日志审计，实现最小权限管理。安全实践：ssh 用 sudo - 而非 su（su 需 root 密码），禁用 su 的 root 登录改用 sudo，wheel 组严格管控。

核心是"环境切换 + 管理员组授权"。su - 加载登录环境，su 保留环境；wheel 组是 sudo 管理员组，实现最小权限。

• sudo -l 输出
• 最小特权审计
• 合规自检

sudo -l 列出当前用户可执行的 sudo 命令（含不带密码的 NOPASSWD 条目），可用于审计该用户被授予的特权。用途：一是合规自检——检查是否有用户被授予超出职责的命令（如普通用户可 sudo 全部或危险命令）；二是最小特权审计——核对每个用户只应拥有完成任务所需的最小命令，删除多余授权；三是检查 NOPASSWD 条目（免密命令）是否过多，避免自动化被滥用；四是检查 ALL=(ALL) 全权授权是否必要。审计方法：批量 sudo -l -U user 查看各用户权限，对照授权矩阵；检查 sudoers 中通配符、路径、危险命令（如 sudo vim/tee 可被利用提权）。合规自检要定期做，输出差异报告，最小特权是安全基线。

核心是"特权可视 + 最小化核对"。sudo -l 陈列权限，审计是否超授权、NOPASSWD 过多、危险命令可被利用。

• sudo/sudo -i/sudo -s 差异
• env_reset 与 secure_path
• 安全意义

sudo 执行命令时以 root（或目标用户）身份，但保留当前环境（受 env_reset 影响）；sudo -s 以 root 启动 shell（保留当前环境变量，非登录 shell）；sudo -i 以 root 启动登录 shell（加载 root 的完整登录环境，类似 su -）。区别：-i 是 login shell（加载目标用户环境），-s 是 shell（保留当前 env），不带参数是执行单命令。env_reset 与 secure_path：env_reset 默认开启，重置环境变量（从安全列表重建，避免继承危险变量如 LD_PRELOAD），防止恶意环境变量提权；secure_path 指定 sudo 使用的安全 PATH（默认 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin），防止 PATH 被篡改导致执行恶意命令。二者合起来防止环境变量注入（LD_PRELOAD、PATH 劫持）导致提权，是 sudo 安全的关键。

核心是"执行方式 + 环境安全"。-i 登录 shell、-s 保留 env；env_reset 重置环境防 LD_PRELOAD，secure_path 固定 PATH 防劫持。

• NOPASSWD 的免密授权
• 自动化中的风险
• 缓解措施

NOPASSWD 让 sudo 命令无需输入密码即可执行，在自动化脚本（CI、cron、ansible）中方便，但隐患明显：一是脚本被攻破/篡改时，攻击者无需密码即可执行授了 NOPASSWD 的命令，扩大攻击面；二是作用域过宽（如 NOPASSWD: ALL）时，任何能执行该脚本/以该用户运行的人都能免密提权；三是难以审计（默认无密码也无第二次认证，无法区分是谁触发的）；四是环境污染（脚本内环境变量、参数注入）。缓解：一是 NOPASSWD 只授予最小必要命令，绝不 NOPASSWD ALL；二是命令白名单精确到具体命令与参数，避免可被利用的编辑器/解释器（sudo vim、sudo tee 可提权）授 NOPASSWD；三是用密钥/凭据隔离与管理（如集中密钥、只读账号）；四是配合日志审计（log_input/log_output）与 credential 过期；五是自动化中用专用低权账号而非 root。核心是"免密但最小化 + 审计 + 隔离"。

核心是"免密放大攻击面 + 作用域"。NOPASSWD 免密被执行，需最小命令白名单、避免可提权命令、配合审计与隔离。

• sudo 时间戳缓存
• timestamp_timeout
• sudo -k 清除

sudo 用时间戳（timestamp）缓存"已认证"状态：一旦用户输入密码通过认证，sudo 记录时间戳（默认在 /run/sudo/ts/ 或 /var/run/sudo/ts），在 timestamp_timeout（默认 5 分钟）内再次执行 sudo 不再要求密码。机制：时间戳按用户+终端记录，timeout 内有效；sudo -k 立即清除当前用户的时间戳缓存，使下次 sudo 需重新输入密码（用于主动清除凭据/防旁人使用）。sudo -K 清除所有（含其他终端）时间戳。sudo -v 更新/激活时间戳而不执行命令。安全意义：时间戳窗口内终端无人看守时，他人可能使用已缓存的 sudo；sudo -k 用于终端退出/离开时清除凭据。可用 sudoers 的 timestamp_timeout 调整窗口（0=每次都要密码，-1=永不超时）。

核心是"时间戳缓存 + 清除"。sudo 认证后缓存 timeout 内免密，-k 清除当前缓存，-K 清全部，调整 timeout 控制窗口。

• NOPASSWD 与 !authenticate
• log_input/log_output
• 安全权衡

NOPASSWD 与 !authenticate 都让 sudo 免密：NOPASSWD 是命令级免密授权，!authenticate 是 Defaults 级的"跳过认证"（对某用户/命令不要求认证）。两者都提升便利但降低认证门槛，被攻破后可直接提权。log_input 记录 sudo 会话的输入（键盘输入），log_output 记录输出，用于审计用户在 sudo 下的操作，可追溯/防篡改，但会产生大量日志与性能开销，且对密码等敏感输入记录需谨慎。安全权衡：NOPASSWD/!authenticate 提供便利却降低安全性，应最小化并只用于可信自动化；log_input/log_output 提升审计能力却增加开销，用于高风险/特权操作。最佳实践：免密只给最小命令、配合 log_input 审计、限制作用域、避免对可提权命令（编辑器/tee）免密。权衡核心是"便利 vs 安全 vs 审计"。

核心是"免密便利 vs 审计开销"。NOPASSWD/!authenticate 降门槛、log_input 增审计，需在最小授权与审计间权衡。

• 共享 key 的责任与审计
• 密钥泄露风险
• 最佳实践

多个管理员共用同一把 root SSH 密钥存在严重问题：一是无法区分身份——所有用同 key 登录的痕迹无法区分是哪个管理员，审计失效（被入侵后无法定位责任人）；二是密钥泄露面大——key 存在于多台终端/多个人，任一设备泄露即威胁 root 权限，且无法精确撤销某个人的访问；三是无法独立管理——某人离职/不再需要权限时，无法单独撤销其访问，只能换整把 key（影响所有人）；四是降低可追溯性。最佳实践：每个管理员独立密钥对，用个人账号 + sudo 提权（而非直接 root 登录），或 root 登录用独立 key 且与个人绑定；用 SSH CA 或 authorized_keys 管理；禁用 root 直接登录（PermitRootLogin no），改用 sudo。核心是"独立 key + 个人账号 + 审计"。

核心是"共享 key 无法审计与撤销"。多个管理员用同 key 无法区分身份、泄露面大、无法单独撤销，应独立 key + sudo。

• 禁用 root 登录理由
• PermitRootLogin 选项
• 最佳实践

生产环境禁用 root SSH 登录理由：一是 root 是攻击者首选目标，暴力破解/利用 root 账号风险高；二是 root 登录无法精确审计（所有 root 操作归一到 root，无法区分操作者）；三是无法最小权限（root 登录即全权，无 sudo 限制）。PermitRootLogin 选项：yes（允许 root 密码/密钥登录，最危险）；no（禁止 root 任何登录，最严格）；prohibit-password（禁止密码登录，但允许密钥登录，用于依赖密钥的 root 场景）；forced-commands-only（root 只能执行指定命令，用于受限自动化）。最佳实践：生产用 no（或 prohibit-password + 独立 key），管理员用个人账号 + sudo 提权，记录审计。这样既防爆破又保证可审计与最小权限。

核心是"防爆破 + 可审计 + 最小权限"。root 是被攻击目标，禁用 root 登录配合 sudo 提权，PermitRootLogin 选项控制密码/密钥。

• 最小特权原则
• sudo 白名单设计
• 提权风险

把所有用户加入 sudoers 会破坏最小权限：每个用户都能提权，攻击面大，被攻破的普通用户可提权 root，且审计混乱。原则：只给确需提权的用户/角色授权，且按职责最小化。sudo 命令白名单设计原则：一是按角色/用户分组（User_Alias、Cmnd_Alias），授权精确到具体命令；二是避免通配符 ALL 与危险命令（sudo vim/tee/less 等可被利用写 root 文件、提权）；三是区分服务命令与运维命令，避免授交互式 shell（sudo -i/vi 等于 root shell）；四是 NOPASSWD 只给最小命令；五是定期审计（sudo -l）与撤销。核心是"谁需要什么、就授什么"的最小授权，避免"人人可 sudo"。

核心是"最小权限 + 白名单"。人人 sudo 扩大攻击面，白名单按角色/命令精确授权，避免 ALL 与可提权命令。

• LDAP/AD 集中账号
• SSSD 与 sudoers 集成
• 协同原则

集中账号（LDAP/AD）通过 SSSD 或其他 NSS 客户端把用户/组同步到系统，认证与授权由集中源管理。与本地 sudoers 协同：SSSD 支持 sudo 集成（sudoers 存 LDAP：sssd 的 sudoku 与 ldap 的 sudo rules），管理员可在 LDAP 中维护 sudo 规则，SSSD 拉取并在本地应用；或保留本地 /etc/sudoers 按用户/组（如 %devops 组）授权，组来自 LDAP。协同原则：一是身份（用户/组）来自集中源，授权（sudo）可在本地或集成 LDAP；二是优先用集中组（如 LDAP 组映射到 sudoers 组）统一管理；三是 SSSD 缓存（cache）保证离线可认证；四是注意 SSSD 的 sudo 缓存与规则刷新（sss_cache）；五是本地有兜底（如 root 保留本地认证）。整体思路：身份集中化、授权可集中或本地、SSSD 是桥接层。

核心是"身份集中 + 授权集成 + SSSD 桥接"。用户/组来自 LDAP/AD，sudo 授权可做在 LDAP 或本地组，SSSD 缓存+同步。

• keytab 的作用与风险
• keytab 敏感性与泄漏
• keytab 轮换

keytab 是 Kerberos 的密钥文件，包含服务/用户主体的长期密钥，用于无交互认证（kinit -kt）自动化脚本。风险：一是 keytab 是敏感凭证，等同长期密码，若权限松散（可读）或被泄露，攻击者可无认证登录/伪装该主体；二是 keytab 长期有效，泄漏后影响面大；三是轮换（更新）复杂，需重新生成并与 KDC/服务同步，自动化中容易疏漏。轮换：用 ktutil 添加/删除条目，或重新生成 keytab 并更新（ktutil addent -password -p service/... -k 1 -e aes256-cts，ktutil wkt），更新 KDC 的密钥（kadmin 的 change_password）、同步到使用方；轮换后需重启依赖服务并验证。最佳实践：keytab 权限收紧（0600/root）、存于安全位置、定期轮换、避免在脚本中硬编码路径、用 vault/凭据管理。最小化：需要时用短暂凭证（kinit 短生命周期）而非长期 keytab。

核心是"keytab 是长期敏感凭证"。"权限收紧 + 定期轮换 + 凭据管理"，泄漏与轮换复杂是主要风险。

• login.defs 的 UID/GID 范围
• 密码老化默认值
• 配置影响

/etc/login.defs 是 useradd/usermod/passwd 等工具的默认配置。UID 范围：UID_MIN（默认 1000）、UID_MAX（默认 60000）定义普通用户 UID 范围；SYS_UID_MIN/SYS_UID_MAX（默认 100-999）定义系统账号 UID 范围；GID_MIN/GID_MAX 对应组。密码老化默认值：PASS_MAX_DAYS（默认 99999，无过期）、PASS_MIN_DAYS（默认 0，可立即改）、PASS_WARN_AGE（默认 7，过期前警告天数）。这些默认值影响 useradd 创建用户与 passwd 老化策略。运维：调整 UID 范围/老化默认值以符合安全基线（如 PASS_MAX_DAYS 设 90），但已有用户不受影响（按用户自身 shadow 字段），新用户用新默认。注意 /etc/login.defs 只是默认值，具体用户可被 chage 覆盖。

核心是"默认值配置"。UID 范围（UID_MIN/MAX）与密码老化（PASS_MAX_DAYS 等）在 login.defs 定义，影响 useradd 新建用户。

• UID 0 的唯一性
• 重复 UID 0 的提权风险
• 审计风险

内核以 UID 0 判定 root 权限，任何 UID 0 的账号都被视为 root，拥有全部特权。因此系统只应存在一个 UID 0 账号（root）。重复 UID 0 账号（如把某账号 UID 改为 0）会带来：一是提权风险——该账号一经登录即获得 root 全部权限，且可绕过 sudo 审计（直接以 root 身份操作）；二是审计风险——管理员在审计日志中难以区分"是 root 还是那个 UID 0 账号"操作，责任不明确；三是绕过管控——独立于 sudo 授权体系，破坏最小权限与审计链。规避：审计 awk -F: '$3==0{print}' /etc/passwd 检查是否存在多个 UID 0；只保留 root 一个 UID 0；发现重复 UID 0 立即调查并修正。这是等保/合规审计重点。

核心是"UID 0 即 root 全权"。重复 UID 0 带来提权与审计无法区分风险，需审计并保持唯一。

• userdel -r 的清理范围
• 失败原因
• 残留处理

userdel 删除用户，-r 同时删除家目录与邮件 spool。userdel -r 失败可能原因：一是家目录被某进程占用（用户仍登录、进程持有文件），删除失败；二是家目录权限/挂载问题（如家目录在 NFS 或只读挂载）；三是 userdel -r 因用户仍在运行而拒绝删除。处理：先确认用户已退出、无进程占用（ps -u user, lsof），必要时 pkill -u user 或用 maintenance 模式；再移除家目录（rm -rf /home/user，注意安全与备份）；移除 /etc/passwd 中条目（userdel 本身或手动）；清理相关 cron、邮件、临时文件。若 userdel 已删除账号但家目录残留，需手动清理并确认属主（避免误删）。安全上先 userdel user（不删除目录）再确认后手动删，避免误删。

核心是"进程占用/权限导致失败"。先确认无进程占用，再手动清理家目录与相关残留，避免误删。

• 两个密码强度模块
• 新旧替代
• 配置差异

pam_cracklib 是旧版密码强度校验模块（基于 cracklib 词典），检查密码过长、含用户名、词典词、字段复杂度；pam_pwquality 是较新的替代（RHEL 7+ 默认），基于 libpwquality，功能相似但更现代、可配置项更多（minlen、dcredit、ucredit、lcredit、ocredit、minclass、dictcheck 等），默认配置在 /etc/security/pwquality.conf。差异：pam_pwquality 是 pam_cracklib 的替代，配置更集中（pwquality.conf）、更灵活、RHEL 8 起默认使用；pam_cracklib 偏旧。两者都用于强制密码复杂度（长度、字符类别、词典）。选型：新系统用 pam_pwquality，旧系统兼容 pam_cracklib。配置要点：minlen（最小长度）、dcredit/ucredit/lcredit/ocredit（数字/大写/小写/特殊字符点数）、minclass（最少类别数）。

核心是"新替代旧"。pam_pwquality 取代 pam_cracklib，配置更集中（pwquality.conf），两者都做密码复杂度校验。

• pam_loginuid 的作用
• auditd 审计
• 协同

pam_loginuid 在登录时设置进程的 loginuid（登录 UID），记录"真正登录用户"的 ID，即使进程切换用户（su/sudo），审计日志也能追溯到原始登录用户。auditd 是内核审计守护进程，记录系统审计事件（登录、命令、文件访问）。协同：pam_loginuid 为审计提供"登录身份"（loginuid），auditd 记录事件时包含 loginuid，使日志能区分"谁登录的"与"当前进程身份"。在一个会话中即使 su 切换了用户，auditd 仍记录 loginuid，实现可追溯。若 pam_loginuid 缺失，loginuid 可能为 -1（不可追溯），审计无法追踪原始登录者。配置：需在 PAM 配置中启用 pam_loginuid（通常在 session 阶段），并确保 auditd 运行。容器环境常禁用 loginuid（容器内无真实登录），需注意。

核心是"loginuid 提供登录身份供审计"。pam_loginuid 记录原始登录用户，auditd 记录时含 loginuid，su 后也能追溯。

• pam_permit 的放行逻辑
• 适用场景
• 风险

pam_permit 总是返回成功（PAM_SUCCESS），即无条件放行认证。它不检查任何凭证，直接授权通过。适用场景：一是某些不需要认证的服务/接口（如某些 public 服务、登录时的某些可选步骤）；二是占位/调试：在模块链中作为占位符，强制某阶段成功；三是配合"不进行认证"的会话（如某些应用服务）。风险：pam_permit 用于认证阶段会完全跳过认证，任何用户都能通过，造成严重安全漏洞。因此只能用于明确不需要认证的场景，且绝不能放在 sshd/login 的 auth 阶段（会被当作"无需密码"）。正确用法：在配置中明确何阶段使用，审计配置避免误用。生产环境除明确需求外应避免 pam_permit。

核心是"无条件放行"。pam_permit 恒返回成功，用于无需认证场景，但绝不能用于 sshd/login 的 auth 阶段否则会绕过认证。

• pam_motd 显示登录横幅
• pam_lastlog 记录/显示上次登录
• 合规审计

pam_motd 在登录时显示 motd（Message of the Day）横幅，可用于展示法律警告/合规提示（如"未经授权禁止访问"），这在等保/合规审计中要求"登录提示"。pam_lastlog 记录上次登录时间并显示（也用于锁定多次失败登录），通过 /var/log/lastlog 记录，配合审计追踪登录历史。合规审计角色：一是 pam_motd 提供登录警告横幅（合规要求），二是 pam_lastlog 记录登录历史用于审计（何时登录、何时失败）。运维：配置 motd 内容（/etc/motd 或 /etc/issue 网络登录），确保 pam_lastlog 在 session 记录；审计时用 lastlog/last 查看登录记录。两者都服务"登录审计与合规提示"。

核心是"横幅 + 登录历史"。pam_motd 显示合规警告横幅，pam_lastlog 记录/显示登录历史供审计。

• PAM 在容器内的生效性
• 容器内 PAM 的必要性
• 镜像精简

容器内 PAM 是否生效取决于使用场景：容器内多数服务（如 nginx、运行时）不依赖 PAM，PAM 只在需要"系统认证"的应用（如 sshd、login、su、sudo）中生效。容器默认以非交互/单用户运行，通常不需要 PAM 认证链，因此可精简。需注意：容器内启动 sshd 时 PAM 生效，需保留相关配置；loginuid 在容器内常为 -1（无真实登录），pam_loginuid 可能报错。镜像精简：一是移除不需要的 PAM 模块与配置（只保留必要的 /etc/pam.d/ 条目）；二是移除 pam_* 二进制与库（若无需认证服务）；三是避免在容器内运行 sshd/login 等需要 PAM 的服务（用 sidecar 或调用宿主认证）；四是减少镜像体积与攻击面。判断：容器是否需要认证服务决定是否保留 PAM。

核心是"按需保留 PAM"。容器内只有认证服务（sshd/su）需要 PAM，多数无需，可精简移除以减小体积与攻击面。

• pam_echo 的作用
• 调试辅助
• 配置

pam_echo 在 PAM 模块链执行时输出指定文本到终端（如显示消息），用于登录调试时确认模块链执行到某一步、验证模块顺序与是否触发。它不影响认证结果，只做信息输出（类似 echo）。辅助作用：在调试 PAM 配置文件时，插入 pam_echo 观察某阶段是否执行、执行顺序，定位认证失败原因；也可用于显示提示信息。配置：auth optional pam_echo.so file=/etc/issue（输出文件内容）或 auth optional pam_echo.so msg="..."。注意 pam_echo 是 optional 类型，不改变认证结果。调试完应移除，避免遗留信息。风险：不要在生产认证链中随意加 pam_echo（可能泄露信息或干扰）。

核心是"调试输出辅助"。pam_echo 输出文本确认模块链执行位置，不改变认证结果，用于登录调试。

• pam_access 限制来源
• pam_time 限制时间
• 配置

pam_access 基于 /etc/security/access.conf 控制访问来源（按用户、组、来源主机/IP、终端），用于限制"谁从哪里登录"（如只允许特定 IP 登录、禁止某些用户从远程登录）。pam_time 基于 /etc/security/time.conf 控制允许登录的时间（按用户、终端、时间段），用于限制"何时登录"（如工作日白天才能登录）。用法：调用前在 PAM 配置的 account 阶段启用（account required pam_access.so、account required pam_time.so），并配置 access.conf/time.conf。场景：安全合规要求限制登录来源与时间窗口；防止异常时间/来源的登录。注意 pam_access 根据 origin 判断，pam_time 按时间规则，两者可组合实现"时间+地点"双重限制。配置错误会导致登录被拒，需测试。

核心是"地点 + 时间控制"。pam_access 按来源主机/IP 限制，pam_time 按时间段限制，在 account 阶段启用。

• pam_env 设置环境变量
• 配置来源
• 边界与安全

pam_env 在登录时设置/更新环境变量，配置来自 /etc/security/pam_env.conf 与 /etc/environment，用于为会话注入环境变量（如 PATH、LANG、特定应用变量）。边界：一是 pam_env 只在登录会话阶段生效，影响会话进程的环境；二是它基于配置文件，可覆盖/设置环境变量，但受变量名与配置规则约束；三是安全性——pam_env 可设置会影响安全的环境变量，需谨慎（如 LD_PRELOAD 类变量若被恶意设置可能注入）；四是只影响该 PAM 触发会话，不是全局。配置：session required pam_env.so 或 auth 阶段，/etc/security/pam_env.conf 中 VAR DEFAULT=value。运维注意：不要用 pam_env 设置危险变量；环境变量设置应最小化；与 systemd 的 Environment 区分（不同机制）。

核心是"会话环境注入 + 安全边界"。pam_env 基于 pam_env.conf/environment 注入环境变量，注意勿设危险变量（LD_PRELOAD）。

• pam_succeed_if 的逻辑
• 条件属性
• 用法

pam_succeed_if 基于属性的条件判断决定是否成功/跳过，用于按条件启用或放行认证流程。它检查用户的属性（如 uid、user、group、shell、home、time），条件满足则返回成功（配合 control 标志实现放行或跳过）。用法：auth sufficient pam_succeed_if.so user ingroup wheel（如果用户属于 wheel 组则放行，跳过后续认证）；account required pam_succeed_if.so uid >= 1000（仅对 UID>=1000 的普通用户应用）；也可按 shell、组、时间（如 time in ... 或靠时间去判断）控制。控制标志结合：sufficient 满足即放行、required 满足才继续、requisite 不满足立即失败。常见场景：只对某些用户/组启用 MFA 或特定认证；跳过对系统账号的认证；按 UID 段差异化策略。条件属性：user、uid、gid、group、shell、home、time 等。

核心是"条件属性 + 控制标志"。pam_succeed_if 按 user/group/uid/shell/time 等条件，结合 sufficient/required 控制放行或跳过。

• chage -l 输出
• 密码老化审计
• 合规

chage -l 列出用户密码老化信息（最近一次修改、密码过期、最小/最大修改天数、警告天数、宽限期、账户过期），用于审计密码策略合规性。作用：一是检查每个用户密码是否按要求定期更换（max days 是否合理）；二是检查是否存在从不过期（99999）的账号，识别弱口令风险；三是检查密码最小间隔、警告天数是否符合基线；四是结合合规（等保）生成密码策略报告。审计方法：chage -l user 查看单个用户，脚本遍历所有用户（for u in $(getent passwd | cut -d: -f1); do chage -l $u; done）找出 max days 异常/从不过期的账号。合规整改：对不符合的用户用 chage -M 设置最大天数。chage -l 是密码老化审计的基础工具。

核心是"查看老化字段 + 发现不合规账号"。chage -l 显示密码过期/最大天数等，审计从不过期或超长账号。

• chsh 修改 shell
• 合法 shell 列表
• 安全审计

chsh 修改用户默认登录 shell（/etc/passwd 第 7 字段）。限制：普通用户只能把 shell 改为 /etc/shells 中列出的合法 shell；root 可改为任意。若 shell 不在 /etc/shells，chsh 会拒绝（除非 root 强制）。安全审计：一是检查是否有用户把 shell 改为可交互 shell（如 sh/bash）从而获得 shell 访问；二是检查 /etc/shells 是否包含安全 shell（避免把 /bin/sh 等危险交互 shell 提供给服务账号）；三是服务账号（nologin 用户）应使用 /usr/sbin/nologin 或 /bin/false 防止登录；四是审计 shell 变更（是否有人把服务账号改为可登录 shell 提权）。chsh -s 指定 shell，echo $SHELL 查看。审计：比对 /etc/passwd 中服务账号 shell 是否为 nologin。

核心是"shell 限制 + 服务账号安全"。chsh 仅允许 /etc/shells 内 shell，服务账号用 nologin，审计 shell 变更防提权。

• pam_faillock 与 pam_tally2 锁定
• 解锁方式
• 审计

pam_faillock（RHEL 8+）与 pam_tally2（旧版）记录登录失败并锁定账户（防暴力破解）。锁定后解锁：faillock 用 faillock --user user --reset 清除该用户失败计数（root 可）；pam_tally2 用 pam_tally2 --user user --reset 或用 faillock --user user --reset（对 faillock）。也需确认锁定策略（deny 次数、unlock_time 时长）。审计：faillock 查看失败记录（含时间、来源），pam_tally2 查看计数；lastb 查看失败登录；/var/log/secure（RHEL）记录失败。运维：锁定后先确认失败原因（暴力破解还是密码错误），再解锁；审计失败来源 IP 决定是否封禁。注意 faillock 与 pam_tally2 是不同模块，解锁命令不同，需对应模块。

核心是"按模块用对应命令解锁"。faillock 用 faillock --reset，tally2 用 pam_tally2 --reset，审计用 faillock/lastb/secure 日志。

• getent 的 NSS 查询
• 身份服务故障
• 退路

getent passwd 通过 NSS（Name Service Switch，/etc/nsswitch.conf）按配置的数据库顺序查询身份信息（本地文件、LDAP、SSSD 等）。身份服务故障时：若 NSS 配置为 files 优先，getent 会先查 /etc/passwd 本地文件，即使 LDAP/SSSD 不可用也能返回本地用户；若配置为 ldap/sss 优先且无缓存，故障时可能查询失败或超时。退路查询：一是确认 nsswitch.conf 中 passwd 数据库顺序（files 应在前面做兜底）；二是用 getent passwd 直接验证 NSS 是否返回正确（区分本地/远程）；三是故障时用本地文件（cat /etc/passwd）作为退路，或用 SSSD 缓存（sss_cache）离线。运维：身份服务故障时 getent passwd 失败不代表本地用户不可用，需检查 nsswitch 顺序与缓存，确保本地 files 兜底。

核心是"NSS 顺序决定退路"。getent 按 nsswitch 顺序查询，files 前置可作兜底，故障时本地文件与 SSSD 缓存是退路。

• id -u 与 whoami
• 有效 UID 与真实 UID
• 服务账号场景

id -u 显示当前进程的有效 UID（effective UID，即进行权限判断的 UID）；whoami 显示当前有效用户名（对应有效 UID）。二者在常规情况下一致（有效 UID 对应当前用户）。差异：在 setuid 程序或服务账号下，进程的有效 UID 可能不同于真实 UID（real UID）。例如服务以 setuid 运行，有效 UID 是 root，但真实 UID 是启动用户；此时 id -u 显示有效 UID（root），而 id -u 与 whoami 都基于有效 UID，通常一致。但 id -u 比 whoami 更精确（whoami 依赖名称解析）。服务账号场景：whoami 可能因 NSS 解析失败（如用户不存在）而报错，而 id -u 直接输出数字 UID 不依赖名称，更可靠。因此脚本中判断当前用户推荐用 id -u（数字、不依赖名称解析）而非 whoami。

核心是"有效 UID vs 名称解析"。id -u 输出数字有效 UID、不依赖名称解析，whoami 依赖名称，服务账号/解析失败时 id -u 更可靠。

• kinit 获取票据
• Kerberos 与 sudo 集成
• 认证流程

在 Kerberos 环境下，用户登录后 kinit 获取 TGT（票据），SSH 可用 GSSAPI 认证；sudo 集成方式：一是 sudo 通过 PAM 的 pam_krb5 或 pam_sss 认证，验证用户 Kerberos 密码或票据；二是 sudo 使用 Kerberos 凭据（已有 TGT）即可认证，无需再输密码；三是 keytab 用于无交互自动化（服务/脚本用 kinit -kt 获取票据后执行 sudo）。集成要点：配置 SSSD/PAM 的 Kerberos 认证（pam_sss 同时处理 Kerberos 与 sudo 的 auth）；sudo 的认证用 PAM 还是 sudoers 的 NOPASSWD；keytab 授权的服务主体需能获取票据并映射到 sudo 用户。安全：keytab 是敏感凭证，需保护；NOPASSWD + keytab 自动化要最小化。整体：Kerberos 提供单点登录，sudo 通过 PAM（pam_sss/pam_krb5）认证或直接已有票据，免二次输入。

核心是"Kerberos 单点 + sudo 认证集成"。sudo 经 PAM 用 Kerberos 认证，keytab 供自动化免交互获取票据。

• newgrp/sg 切换有效组
• 会话与命令
• 差异

newgrp 切换当前 shell 的有效组（GID），并启动一个新 shell（如 newgrp dev 切换到 dev 组）；sg 与 newgrp 类似但执行命令而非启动 shell（sg dev -c 'cmd' 在 dev 组下执行命令）。差异：newgrp 进入一个新 shell 会话（需该组是用户组成员或输入组密码），sg 执行单个命令后返回。两者都改变有效组（effective GID），使新建文件归属目标组。注意：仅当用户已是该组成员时才无需密码；否则需组密码。切换后新创建的文件属组为切换后的组。应用：在共享目录中临时切换有效组以便创建文件归属正确组。现代更常用 sg 或 sudo 的组切换，newgrp 较传统。

核心是"切换方式不同"。newgrp 启动新 shell 切换有效组，sg 执行单命令后返回，二者都改有效 GID。

• pam_tally2 与 pam_faillock
• 迁移原因
• 配置迁移

pam_tally2 是旧版登录失败锁定模块，RHEL 8 起被 pam_faillock 取代。取代原因：pam_faillock 更稳定、支持更现代的锁定策略（如收听 pam_faillock 服务、更清晰的 deny/unlock_time 配置），且与 console 认证、SSH 集成更好。迁移：一是把 /etc/pam.d/ 中 pam_tally2 条目替换为 pam_faillock（preauth + authfail + 三段式配置）；二是配置 /etc/security/faillock.conf（deny、unlock_time、silent 等）替代 pam_tally2 的参数；三是用 faillock 命令替代 pam_tally2 命令查看/解锁；四是验证锁定策略一致。注意 pam_faillock 需在 auth 阶段配置 preauth 与 authfail 两处，且 session 中不需要。迁移后审计与解锁用 faillock。

核心是"模块替换 + 配置迁移"。pam_faillock 取代 pam_tally2，用 faillock.conf 与 faillock 命令，配置 preauth/authfail 两段。

• setpriv/runuser/chroot 的作用
• 无 root 容器沙箱
• 边界

setpriv 以指定 UID/GID/能力运行命令（setpriv --reuid=1000 --regid=1000 --clear-groups cmd），用于降权执行；runuser 以指定用户运行命令（类似 su 但无需 root 密码，适合 root 调用）；chroot 改变进程的根目录（jail），把进程限制在指定目录内。无 root 容器沙箱边界：这三个工具在"无 root 容器"（用户命名空间）中的能力受限制——setpriv 降权在容器内有效，但无法提权到容器外；chroot 只能限制目录可见性，不能限制内核访问（不能阻止 syscall/网络/设备），需配合 seccomp、capabilities、命名空间；runuser 在无 root 容器内无法真正切换 root（无权限）。沙箱边界：chroot 非真实隔离（可逃逸，需 chroot + seccomp + 命名空间），setpriv 做降权，runuser 做身份切换。真正的沙箱需 cgroup/namespace/seccomp 组合，chroot 只是目录隔离。

核心是"目录隔离 vs 真实隔离"。chroot 只限制根目录可逃逸，setpriv 降权、runuser 切身份，无 root 容器需 seccomp/namespace 组合才算沙箱。

• sss_cache 清理缓存
• LDAP 修改生效
• 强制刷新

sss_cache 是 SSSD 的缓存清理工具，sss_cache -E 清除所有缓存（用户、组、sudo 等），sss_cache -u user 清某用户、-g group 清某组。工程意义：SSSD 缓存用户/组/身份信息以提升性能并支持离线，但缓存有 TTL，LDAP 修改（新增用户、改组、改 sudo 规则）可能不会立即反映到本地。修改后执行 sss_cache -E 强制刷新缓存，使变更立即生效，避免运维等待缓存过期或应用查询到陈旧数据。典型场景：LDAP 新增用户/调整组后，本地 getent 仍显示旧数据，执行 sss_cache -E 使新用户/组立即可用。注意：sss_cache 只清客户端缓存，LDAP 端不变；需 SSSD 运行。相比重启 sssd、清 nscd 缓存，sss_cache 更精准。

核心是"强制刷新缓存使 LDAP 变更立即生效"。sss_cache -E 清全部缓存，避免陈旧数据，-u/-g 精准清。

• env_reset 与 env_keep
• 环境变量白名单
• 权限边界

env_reset 默认开启，sudo 执行时会重置环境变量（从安全列表重建，丢弃可能危险的环境变量如 LD_PRELOAD、LD_LIBRARY_PATH）；env_keep 指定哪些环境变量被保留（Defaults env_keep += "VAR"），即从用户环境保留指定变量到 sudo 环境。权限边界：env_reset 重置环境，防止危险变量（LD_PRELOAD 等）污染 sudo 提权后的进程；env_keep 是白名单，只有显式列出的变量才保留。若 env_keep 错误地保留危险变量（如 LD_PRELOAD、PATH 被篡改），可能绕过 env_reset 的安全保护，导致提权或命令注入。因此 env_keep 应与 env_reset 结合，严格限制保留的变量，避免保留可由用户控制并影响安全的环境变量。secure_path 也配合固定 PATH。边界：env_reset 保证安全基线，env_keep 是可控例外，二者结合实现"重置 + 白名单保留"。

核心是"重置 + 白名单保留"。env_reset 重置环境防危险变量，env_keep 只保留列出的变量，错误保留危险变量会破坏安全边界。

• sudo 与 doas 的起源
• 配置与安全
• 取舍

doas 起源于 OpenBSD（2015 年，随 OpenBSD 5.8 发布），作为 sudo 的替代，设计更简洁、更小、更安全（配置简单、攻击面小）；sudo 起源更早（1980 年代），功能丰富、配置复杂、跨平台广泛部署。差异：doas 配置（/etc/doas.conf）更简单（permit keepenv user as root cmd），代码量小、审计面小、OpenBSD 默认；sudo 功能强大（sudoers 粒度、日志、时间戳、NOPASSWD、多平台），但配置复杂、攻击面大。取舍：追求简洁安全、OpenBSD 系用 doas；需要丰富功能、跨平台、细粒度授权用 sudo。doas 在 Linux 也有移植（如 doas 包），但 sudo 仍是主流。工程上：简单场景 doas 更易维护，复杂权限/审计场景 sudo 更成熟。安全上 doas 更小更易审计，但 sudo 功能多。

核心是"简洁安全 vs 功能丰富"。doas 源自 OpenBSD、简洁小安全，sudo 功能丰富广泛、配置复杂。

• sudo 与 polkit 的定位
• 桌面/服务器场景
• 边界

sudo 是命令行/服务器场景的提权工具，通过 sudoers 授权用户在终端执行特权命令；polkit（PolicyKit）是系统级授权框架，用于管理桌面/服务向非特权进程授权（如 NetworkManager 改网络、systemd 管理服务、桌面挂载），基于 system bus 的 Action 与授权规则（/etc/polkit-1/rules.d）。边界：sudo 面向"终端命令提权"（服务器、运维），polkit 面向"桌面/服务授权"（非交互、GUI 场景、D-Bus 服务调用）。服务器场景多用 sudo（命令提权），桌面/服务管理场景用 polkit（如 systemctl 非 root 用户、桌面弹窗授权）。两者互补：sudo 管命令，polkit 管服务/系统授权。运维中服务器少用 polkit，桌面/容器桌面多用 polkit。

核心是"命令提权 vs 服务授权"。sudo 面向终端命令（服务器），polkit 面向桌面/服务/D-Bus 授权。

• sudo 日志来源
• auditd 与 syslog 集成
• 防篡改

sudo 默认经 syslog 把日志写入 /var/log/secure（RHEL 系）或 /var/log/auth.log（Debian 系）。防本地篡改：一是把 sudo 日志集中到 auditd——sudo 的审计事件（Execve 等）通过 curl 到 auditd 记录，auditd 可配置本地防篡改（只读、实时）；二是把 sudo 日志转发远端 syslog——在 sudoers 配置 Defaults logfile 与 Defaults syslog，或把 /var/log 转发到集中日志（rsyslog 远程服务器/splunk），日志在远端保留，本地篡改无法影响远端。做法：sudoers 中 Defaults syslog=auth、Defaults log_input, log_output 记录更详细；rsyslog 配置把 sudo 日志转发到远端（*.* @logserver:514）；auditd 用 auditctl -w 监控 sudo 相关文件。防篡改核心：日志写入远端只读/集中存储，本地权限收紧，审计日志独立不可改。

核心是"日志远端化 + 审计"。sudo 日志经 syslog 转发远端、auditd 审计事件，本地篡改不影响远端，实现防篡改。

• includedir 与 @include
• 多团队配置
• 管理

sudoers 的 #includedir /etc/sudoers.d 指示加载目录下所有文件（每文件一个配置片段），@include 语法（sudo 较新版本）类似但更灵活（可指定文件/目录）。多团队配置角色：每个团队/应用可维护自己独立的 sudoers 片段文件（如 /etc/sudoers.d/team-dev），互不干扰，便于按团队授权、版本管理与审计。好处：一是隔离——团队只改自己的文件，避免直接改主 sudoers 冲突；二是模块化——按团队/应用拆分，职责清晰；三是便于自动化（跳入目录管理）；四是权限控制（目录内文件权限需 0440）。注意事项：includedir 下文件不能有语法错误（否则 sudo 全坏），需用 visudo -c 校验；文件名不能含点；文件权限 0440。多团队建议用 includedir 拆分 + 定期校验。

核心是"配置拆分 + 隔离"。includedir/@include 让多团队各自维护独立片段，需校验语法与权限 0440。

• 单一 vs 拆分
• 可维护性
• 管理

单一 sudoers 文件集中所有 sudo 配置，管理简单、全局一目了然，但随团队/应用增多会变得庞大、易冲突、难以按团队委派维护。sudoers.d/ 目录按团队/应用拆分多个片段文件，模块化、隔离、便于自动化与版本管理，但需注意片段间规则顺序、语法校验与权限。可维护性比较：单一文件适合小规模、集中管控；sudoers.d/ 适合多团队、应用隔离、需要各自维护的规模化场景。实践上多采用混合：主文件放全局 Defaults，sudoers.d/ 放各团队/应用条目。维护要点：拆分后每次修改用 visudo -c 校验（防止语法错误导致 sudo 全坏）；文件权限 0440；命名规范（避免点号）；定期审计。sudoers.d/ 提升可维护性（隔离、按域管理），但需纪律与校验。

核心是"集中 vs 模块化"。单一文件集中但易膨胀冲突，sudoers.d/ 按团队拆分更易维护，需校验与纪律。

• useradd -r 系统账号
• 家目录策略
• 差异

useradd -r 创建系统账号（system account），UID 在系统范围（SYS_UID_MIN/MAX，默认 100-999），默认不创建家目录（除非 -m 显式指定），且不创建邮件 spool，shell 建议用 nologin。普通账号（useradd 不加 -r）UID 在普通范围（1000+），默认创建家目录（-m）并复制 /etc/skel 模板。差异：一是 UID 范围不同（系统低 UID、普通高 UID）；二是家目录——系统账号默认无家目录（或无登录家目录），普通账号默认创建；三是 shell——系统账号默认 nologin（防登录），普通账号默认 /bin/bash；四是用途——系统账号用于运行服务，普通账号用于用户登录。策略：系统账号用 -r -s /usr/sbin/nologin，不建家目录或用受限家目录；普通账号 -m 建家目录。安全：服务账号最小权限、无登录。

核心是"UID 范围 + 家目录 + shell"。-r 系统账号低 UID、默认无家目录、nologin，普通账号建家目录可登录。

• sudoedit 机制
• 编辑器以调用者身份
• 配置

sudoedit 允许用户以"调用者身份"编辑特权文件：sudo 把目标文件复制到临时文件（属主是调用者），用户用编辑器（以调用者身份运行，非 root）修改临时副本，保存后 sudo 校验并把内容写回原文件。这样编辑器不继承 root 权限，避免编辑器以 root 运行被利用（编辑器提权风险）。配置：在 sudoers 中授权 alice ALL=(root) NOPASSWD: /usr/bin/sudoedit /etc/nginx/nginx.conf，指定可编辑文件。使用：sudoedit /etc/nginx/nginx.conf。编辑过程：临时副本在 /tmp 或 /var/tmp，属主为调用者，编辑器（如 vi）以普通用户运行，修改的是临时文件；保存后被 sudo 写回。安全边界：编辑器无法直接改原文件权限/属主，无法利用编辑器提权；用户只能编辑被授权的文件。注意编辑器需在 sudoers 的 editor 列表（Default editor）。

核心是"临时副本 + 调用者身份编辑"。sudoedit 复制到临时文件，编辑器以调用者身份运行免 root 提权风险，保存后 sudo 写回。

• pam_faillock 与 pam_tally2 差异
• 锁定阈值
• 解锁方式

pam_faillock（现役，RHEL 8+）与 pam_tally2（旧版）都实现登录失败锁定。实现差异：pam_faillock 用 /var/run/faillock 目录记录每个用户失败计数，需在 auth 阶段配置 preauth 与 authfail 两段，支持 deny、unlock_time、silent、root_unlock_time 等；pam_tally2 用 /var/log/tallylog 记录，配置以命令行参数传入（deny=、unlock_time=、lock_time=）。锁定阈值：deny 指定失败次数（如 deny=5 第 5 次失败锁定），unlock_time 指定锁定时长（秒）。解锁方式：pam_faillock 用 faillock --user user --reset（root）；pam_tally2 用 pam_tally2 --user user --reset。差异要点：faillock 更现代、配置集中（faillock.conf）、支持 root 锁定策略；tally2 旧。阈值与解锁需按模块用对应命令。审计：faillock 查看失败记录。

核心是"模块差异 + 阈值 + 解锁命令"。faillock 用 faillock.conf/faillock 命令，tally2 用参数/pam_tally2 命令，deny 定阈值、unlock_time 定时长。

• SSSD 缓存
• 离线登录
• 集中身份

SSSD（System Security Services Daemon）是 RHEL 系集中身份（LDAP/AD/Kerberos）的客户端，统一管理用户/组/认证/缓存。缓存与离线登录能力：SSSD 把从 LDAP/AD 获取的用户/组/认证信息缓存到本地（/var/lib/sss/db），在集中服务不可达时仍能基于缓存认证（离线登录），保证网络故障时本地用户可登录。缓存策略：内存缓存（冷热）、磁盘缓存（持久），可配置 TTL（ldap_search_timeout 等），支持 sss_cache 手动刷新。离线登录：SSSD 缓存成功认证过的凭据（缓存密码），集中服务不可达时用缓存验证。注意：首次认证需在线（缓存需先建立），离线只能认证已缓存用户；密码变更需在线同步。工程意义：集中身份 + 缓存容错 + 离线登录，提升可用性同时保证一致性。

核心是"缓存容错 + 离线认证"。SSSD 缓存用户/组/凭据，集中服务不可达时离线登录，需先在线建立缓存。

• useradd 选项
• usermod -aG
• 主组覆盖

useradd 创建用户：-m 创建家目录、-s 指定 shell、-G 指定附加（补充）组列表（逗号分隔）。usermod -aG 修改用户附加组：-a 追加（append），-G 指定组列表。差异：useradd -G 在创建时设附加组；usermod -G 修改附加组，但若不加 -a 会"覆盖"现有附加组（把用户从原组移除，只保留新指定组），导致用户丢失原有组权限；usermod -aG 追加，保留原组。避免覆盖主组：附加组是补充组，主组（primary group）由 -g 或默认创建，修改附加组不要碰主组；用 usermod -aG 追加避免覆盖已有附加组。教科书：usermod -aG docker alice（追加，勿忘 -a）。主组改变需谨慎（影响文件归属）。

核心是"-G 覆盖 vs -aG 追加"。usermod 不加 -a 会覆盖附加组，用 -aG 追加保留原组，主组独立不受影响。

• usermod -L 与 passwd -l
• 锁定机制
• 差异

usermod -L 与 passwd -l 都锁定账户，但机制与表现形式略有差异。usermod -L 在 /etc/shadow 密码字段前加 !（锁定密码），passwd -l 同样在密码字段前加 !（prepend !）。实际上两者都是通过修改 shadow 密码字段（加 ! 前缀）使密码失效，达到锁定。差异：一是命令语义不同（usermod 管理用户属性，passwd 管理密码），但锁定效果相同；二是 passwd -l 更直观（锁定密码）；三是 usermod -L 对某些系统可能同时锁定，passwd -l 只加 !。解锁：usermod -U 或 passwd -u 移除 ! 前缀。注意：锁定密码（!）只阻止密码认证，不阻止密钥登录（SSH 密钥可绕过）；若需彻底禁用登录需配合 shell 改为 nologin 或禁 root。审计：查看 shadow 中密码字段是否带 !。

核心是"二者都加 ! 锁密码"。usermod -L 与 passwd -l 都在 shadow 密码字段加 ! 锁定，但只锁密码认证不拦密钥登录。

• nscd 与 sssd 缓存
• 冲突与陈旧数据
• 运维建议

nscd（Name Service Cache Daemon）与 sssd 都缓存 passwd/group/主机名，同时运行会重复缓存、引发冲突与陈旧数据。问题：一是双重缓存——nscd 缓存 sssd 的查询结果，sssd 又缓存 LDAP，两层缓存导致数据过期更严重；二是刷新不一致——sss_cache 清 sssd 缓存，但 nscd 缓存仍旧，查询仍返回旧数据；三是缓存冲突——两端缓存 TTL 不同步，更新后一端新一端旧，getent 结果不确定；四是性能与内存重复。生产建议：SSSD 已内含缓存，无需 nscd 再缓存 passwd/group，应禁用 nscd（或仅用于 host 缓存），避免双缓存。规范：用 sssd 就不要用 nscd 缓存 passwd/group，改数据用 sss_cache 刷新并确认 nscd 未拦截。排查陈旧数据：看 nscd 是否运行、两端缓存、sss_cache -E 刷新。

核心是"双重缓存冲突"。nscd 与 sssd 都缓存 passwd/group 导致陈旧与刷新不一致，SSSD 已含缓存，应避免 nscd 缓存 passwd/group。

• UID 修改与缓存
• nscd/sssd 缓存
• 刷新

修改用户 UID（或改组）后，ls 显示陈旧属主的原因：ls 把 UID 映射为用户名时会查询 NSS（passwd 数据库），若 nscd/sssd 缓存了旧 UID→用户名映射，查询会返回缓存的旧信息，即使 /etc/passwd 已更新。此类问题多因 nscd 缓存 passwd 未刷新。处理：刷新 nscd 缓存（nscd -i passwd 使 passwd 缓存失效，或重启 nscd）；若用 sssd，用 sss_cache -E；确认 NSS 顺序（files 是否优先）。若 nscd 缓存了 passwd，即使改了文件，getent/ls 仍显旧值。预防：对集中/本地用户，改 UID 后及时刷新对应缓存；nscd 与 sssd 不重复缓存 passwd。本质：ls 的属主显示依赖 NSS 查询，缓存未刷新导致陈旧。

核心是"NSS 缓存未刷新"。改 UID 后 nscd/sssd 缓存旧映射，用 nscd -i passwd 或 sss_cache -E 刷新。

• 缓存失效与故障
• nscd/sss_cache
• 排查

集中账号缓存（nscd/sssd）失效时的常见故障：一是陈旧数据——用户/组变更后 getent 仍返回旧值（缓存未刷新），导致权限/属主错误；二是缓存与源不一致——LDAP 改了但 nscd/sssd 缓存未同步，新用户无法登录或旧用户被误删；三是缓存损坏——nscd/sssd 缓存文件损坏导致查询失败、服务卡顿；四是双缓存冲突——nscd 与 sssd 同时缓存 passwd 导致刷新不一致。处理：缓存失效（陈旧）用 nscd -i/sss_cache -E 刷新；缓存损坏清空缓存目录（/var/lib/sss/db、/var/cache/nscd）并重启服务；确认 nsswitch 顺序与缓存配置；检查服务日志（sssd 日志）。排查流程：先看 getent 是否返回旧数据，再确认 nscd/sssd 状态与缓存，刷新/重建缓存，验证源端数据。

核心是"缓存陈旧/损坏/冲突"。故障表现为数据陈旧或查询失败，用 sss_cache -E/nscd -i 刷新或清缓存重建。

• 身份源切换
• 灰度过渡
• 回退

从 OpenLDAP 切换到 AD 需谨慎，避免影响所有用户登录。灰度策略：一是并行验证——先让 test 环境/少量机器切换到 AD，验证用户/组/认证/权限正确；二是分段灰度——按机器/用户组逐步切换（先非核心，再核心），每步验证；三是保持 OpenLDAP 可用——切换期间保留旧源，SSSD 配置可回退；四是同步数据——确保 AD 已有正确的用户/组与密码（或迁移密码），避免切换后用户缺失；五是验证 sudo 规则、家目录、权限映射。回退策略：一是配置层面可快速回退（SSSD 配置切回 OpenLDAP）；二是保留 OpenLDAP 只读作为回退；三是用灰度开关（如 SSSD 的 provider 配置切换）；四是监控登录失败率、用户查询，异常立即回退。整体：先验证、再灰度、可回退、有监控。

核心是"灰度 + 回退"。先并行验证、分段灰度、保留旧源可回退，监控异常立即回退。