服务器用户管理底层原理如何学

Linux用户管理核心是“谁在管、怎么认、凭什么能干”：UID/GID数字标识身份，/etc/passwd存元数据而密码在/etc/shadow加密存储，家目录由/etc/skel复制生成，组权限需结合setgid与目录权限位协同生效。

学服务器用户管理的底层原理，关键不是背命令，而是理解“谁在管、怎么认、凭什么能干”这三件事。它不是孤立的知识点，而是贯穿整个Linux权限体系的骨架。

用户身份靠UID和GID识别，不是用户名

系统内核不认“alice”或“root”这种名字，只认数字：UID 0 是 root，UID 1001 是普通用户，GID 同理。/etc/passwd 里那行 alice:x:1001:1001::/home/alice:/bin/bash，真正起作用的是第三、四字段（UID/GID），名字只是给人看的别名。ls -l 显示的用户名，其实是系统查 /etc/passwd 把 UID 反向映射出来的——所以改用户名不影响权限，改 UID 才真改身份。

密码不存 /etc/passwd，而是在 /etc/shadow 里加密锁着

passwd 文件里的 x 不是密码，只是一个占位符，表示真实密码藏在更严格的 shadow 文件中。shadow 权限是 000（仅 root 可读写），且密码用 SHA-512 加盐哈希（字段开头 $6$ 就是标识）。密码策略（比如90天过期、7天前提醒）也全靠 shadow 里对应字段控制，不是靠命令临时生效。

家目录不是自动“生成”的，是创建用户时复制模板来的

执行 useradd -m alice 时，系统会从 /etc/skel 目录把 .bashrc、.profile 等文件复制到 /home/alice，再设权限为 700（仅用户自己进得去）。这个过程可定制：用 -k /path/to/custom_skel 指定模板，避免每次都要手动配置开发环境。

组权限不是“加个组就自动有权限”，得配合目录的 setgid 和权限位

比如开发组 developers 的成员想共享编辑 /project/app，光 usermod -aG developers alice 不够。还得：

1. chown :developers /project/app
2. chmod 2775 /project/app（2 表示 setgid，确保新文件自动继承组）
3. 目录本身要有 rwx 给组，否则进都进不去

权限检查是“所有者→所属组→其他人”顺序短路判断

一个文件属主是 alice，属组是 developers，权限是 rw-rw----。当用户 bob（不在 developers 组）访问时，系统先看他是不是 alice → 不是；再看他是否在 developers 组 → 不是；最后按 others 处理 → 没任何权限。不会因为 bob 是 sudoer 就绕过——sudo 是提权执行命令，不是改文件权限逻辑。

不复杂但容易忽略