/etc/passwd共7字段，用:切分但需防第7字段含参数；/etc/shadow共9字段、仅root可读，第2字段为哈希，须校验格式；不一致导致登录失败或审计告警。
passwd 文件每行字段怎么拆解
直接用 : 切分就行，但别硬写 split(':') 就完事——第 1、2、5、6 字段可能含空格或逗号，而第 7 字段（shell 路径）可能带参数（比如 /bin/sh -c），实际系统里极少这么用，但解析脚本得防住。标准字段共 7 个，顺序固定：
-
username：登录名，不可为空，不支持:和空格 -
password：早期明文密码占位，现在全是x或*，真密码在/etc/shadow -
uid：数字，0 是 root，1–999 通常是系统用户（不同发行版范围略有差异） -
gid：主组 ID，对应/etc/group中的组 -
gecos：逗号分隔的用户信息（全名、办公室、电话等），可为空，但字段本身不能省略 -
home_dir：必须是绝对路径，/root、/home/alex这类，不检查是否存在 -
shell：必须是可执行文件路径，/bin/bash、/usr/sbin/nologin算合法；空值或非法路径会导致 login 失败，但passwd文件本身仍算语法正确
shadow 文件权限和字段含义
/etc/shadow 默认权限是 000（即 ----------），只有 root 可读——普通用户连 ls -l 都看不到内容，更别说解析。字段共 9 个，用 : 分隔，第 2 字段（密码哈希）是核心：
-
username：必须与/etc/passwd中一致，否则登录时找不到匹配项 -
password_hash：以$id$salt$hash格式存储，id=1是 MD5，id=6是 SHA-512（主流），id=ya是 yescrypt（较新）。空值（::）表示无密码；*或!表示锁定账户 -
last_pwd_change：从 1970-01-01 起的天数，不是秒数；值为0表示下次登录强制改密 -
min_days：两次改密最小间隔（天），0表示不限制 -
max_days：密码有效期（天），99999常见，等于约 273 年 -
warn_days：过期前多少天开始警告用户 -
inactive_days：过期后多少天禁用账户（设为0表示立即禁用） -
expire_date：账户绝对过期时间（从 epoch 起的天数），1表示 1970-01-02，-1表示永不过期 -
reserved：保留字段，目前始终为空
用 Python 安全读取 shadow 的常见错误
想用 open('/etc/shadow')？非 root 用户会直接报 PermissionError: [errno 13] Permission denied。绕过权限检查（比如用 sudo python script.py）也不推荐——脚本一旦有 bug，可能意外泄露哈希。真实场景中，应该：
- 只在 root 权限下运行，且明确检查
os.geteuid() == 0 - 避免把整行
password_hash打印或记录到日志，哪怕只是调试 - 别用
csv.reader解析，它默认处理引号和转义，而 shadow 没这些规则，纯line.strip().split(':', 8)更可靠（注意切 8 次，确保最后字段包含所有剩余内容） - 对
password_hash字段做基础校验：以$开头、至少含两个$、长度 >10，能过滤掉明显异常值（比如空字段或*后多出的垃圾字符）
passwd 和 shadow 字段不一致会怎样
系统不会在写入时强校验一致性，所以人工编辑或脚本出错后，问题往往延迟暴露：
-
/etc/passwd里有用户alice，但/etc/shadow没这行 → 登录时提示Authentication failure，实际是找不到密码记录 -
/etc/shadow里有bob，但/etc/passwd没这行 →usermod或passwd命令会报user bob does not exist，但系统启动或 PAM 加载时通常不报错 -
uid在 passwd 里是1001，但 shadow 里对应行写成1002→ 不影响登录，因为 shadow 根本不看 uid，只认 username；但后续用getent passwd bob查到的 uid 和getent shadow bob返回的字段是割裂的，审计工具可能告警
真正麻烦的是跨字段逻辑耦合：比如 home_dir 设为 /nonexistent，而 shell 是 /bin/bash，用户能登录但立刻被踢出——这种问题不在文件格式层面报错，得靠实际测试。