1. 从一次线上事故说起：为什么必须搞懂用户与组管理
先讲个我实际踩过的坑。有次给一台服务器部署应用，图省事直接用 root 账号登录，把代码丢到/root目录下就跑了。结果第二天发现服务起不来，排查半天，是某个子进程需要读取/var/log下的日志文件，但日志目录属主是其他用户，权限位是 644，子进程压根没权限写。那会儿我才意识到：Linux 里所有文件、进程、网络连接背后都挂着“属主”和“属组”的身份标签，搞不清用户、组、权限这三者的关系，系统管理早晚要出事。
Linux 用户与组管理是整个系统安全模型的基石，它决定了谁能登录系统、谁能读取哪个文件、谁能执行哪个程序、谁能管理哪些服务。无论你是刚接触 Linux 的入门者，还是在职的系统运维工程师，甚至是为考认证做准备的学生，这一块都是绕不开的核心技能。这篇文章我不打算照搬 man 手册，而是把我实际操作中的理解、命令用法、踩过的坑一起梳理出来，尽量让零基础的朋友也能跟着上手。
很多人会问：既然 Linux 默认就有一个 root 超级用户，为什么还要折腾普通用户和组？答案很简单——权限最小化原则。日常操作和运行服务时，普通权限就够了；只有安装软件、修改系统配置这些操作，才需要临时切换到 root 身份。这样即使某个服务被入侵，攻击者拿到的也只是一个受限用户的权限，损失可控。用户和组的管理，本质上是给系统里的人与进程划分“活动范围”。
2. 核心设计思路拆解：Linux 如何用“身份”来管住一切
2.1 用户与进程的关系模型：你操作的其实是“身份令牌”
Linux 是典型的多用户多任务操作系统。所谓多用户，并不是说一台机器上真坐着好几个人，而是系统内核通过用户 ID（UID）来区分不同的操作主体。你在终端敲下的每一条命令，最终都会以某个用户身份去执行；你启动的每个进程，都会被打上启动者的 UID 和 GID（组 ID）标签。内核在检查文件访问权限时，看的就是这个进程身份标签对比文件属主属组的结果。
打个比方：整个 Linux 系统像一栋大楼，root 是拥有万能钥匙的物业总负责人，普通用户就是租户。租户只能打开自己租的那间办公室，公共区域（比如 /tmp）大家都能进，但别人的房间你硬闯就会撞上门禁。进程就是你在楼里走动的“临时通行证”，通行证上的身份信息决定了你能走到哪一层、推开哪一扇门。组则是大楼里的部门划分——财务部、技术部、行政部门，部门成员共享某些公共资源的使用权。
需要注意一个细节：用户和进程之间还有一个“有效身份”的概念。当你用sudo执行命令时，进程的实际 UID 还是你的普通用户 UID，但有效 UID 变成了 root，于是内核认为这个进程拥有 root 的访问权限。这也是为什么后来出现了 suid/sgid/sticky 位这些权限扩展机制——它们都是基于“身份”这套模型演化出来的精细化控制手段。
2.2 组的本质：不是给文件分类，是给权限批量授权
组的核心价值在于“批量授权”。假设系统里有 10 个人都需要读取某个项目的代码目录，如果没有组的概念，管理员就得挨个把这 10 个人加入目录的 ACL 或者干脆把目录权限开成 777——前者繁琐，后者危险。有了组，你只要建一个名为 dev 的组，把 10 个人都塞进去，再把目录属组改成 dev、权限设为 770，所有问题一次性解决。
Linux 组分两种：基本组（主组）和附加组（补充组）。新用户创建时系统会默认创建一个与用户名同名的组，作为该用户的主组。用户还可以被加入若干附加组，从而获得额外资源的访问权限。比如某用户主组是 alice，但同时属于 docker 附加组，那他就能调用 docker 命令组里的 socket 接口。
这种“主组 + 附加组”的设计，让权限管理变得非常有弹性：主组解决“这个用户默认属于哪个部门”的问题，附加组解决“这个人还兼职了哪些岗位”的问题。日常运维里最常见的场景，就是给某个 Web 服务账号添加附加组，让它既能读代码又不能随便动其他系统目录。
2.3 为什么推荐“最小权限”思路：安全不是靠防火墙堆出来的
很多新手觉得安全是防火墙、杀毒软件的事，其实大错特错。系统内部的身份与权限管控才是安全的最后一道防线。你想象一个场景：一台对外提供 Web 服务的服务器，Nginx 进程如果用 root 身份运行，一旦 Web 应用有代码执行漏洞，攻击者直接拿到了 root 权限，整台机器就沦陷了。但如果你事先建了一个 www 用户，把网站目录属主设为 www，让 Nginx 以 www 身份运行，攻击者即使打穿了应用层，能控制的也只是那个目录里的一亩三分地。
这也是我在实践中的一条铁律：能用普通用户跑的服务绝不用 root 跑；能分配最小权限就绝不放开多余权限。MySQL、Redis、Nginx 这类服务，安装完第一步就是检查它是否以独立专用用户运行。搞用户与组管理，本质上就是在做“系统内部的边界划分”。
3. 核心配置与实操：四个关键文件逐一拆解
3.1 /etc/passwd：字段不长，每个都值钱
用户账号的静态信息都存在/etc/passwd里。一行代表一个用户，用冒号分隔成 7 个字段。我用 awk 命令拉一行出来看：
awk -F: '/^root/{print $0}' /etc/passwd输出类似：
root:x:0:0:root:/root:/bin/bash逐字段拆开说是这样的：
| 字段位置 | 示例值 | 含义 |
|---|---|---|
| 1 | root | 用户名 |
| 2 | x | 密码占位符（真实密码放在 shadow 文件） |
| 3 | 0 | UID，用户 ID |
| 4 | 0 | GID，主组 ID |
| 5 | root | 用户描述信息（GECOS 字段，一般写全名或注释） |
| 6 | /root | 家目录路径 |
| 7 | /bin/bash | 登录 Shell |
第二字段为什么是 x 而不是真实密码？这是出于安全考虑。上古时代的 Unix 确实把加密后的密码放在这个字段里，但 /etc/passwd 是所有用户都必须可读的（很多命令要读取它解析用户名到 UID 的映射），密码哈希等于对所有人公开，暴力破解就没门槛了。后来系统把密码哈希挪到了只有 root 能读的 /etc/shadow 文件里，passwd 文件的第二字段就用 x 作为占位符。
这里有个反直觉的细节：UID 为 0 的不止 root 一个。你完全可以把另一个用户名也设置成 UID 0，那个用户就拥有和 root 同等的超级权限。安全加固时，我建议定期检查有谁的 UID 是 0，确保没有意外多出来的“隐藏 root”。
3.2 /etc/shadow：密码哈希与账号生命周期都在这
/etc/shadow的权限默认是 640，属主 root，属组 shadow。普通用户无权读取，只有 root 和 shadow 组成员能看。这个文件一行一个用户，同样是冒号分隔，重点看前几个字段：
root:$6$8Xk...:18886:0:99999:7:::以 root 那行为例：
| 字段位置 | 示例值 | 含义 |
|---|---|---|
| 1 | root | 用户名 |
| 2 | $6$8Xk... | 密码哈希（$6$ 表示 SHA-512 算法） |
| 3 | 18886 | 最近一次修改密码的时间戳（从 1970-01-01 起的天数） |
| 4 | 0 | 最短修改期限（多少天后才能再改密码） |
| 5 | 99999 | 密码有效期（天数，99999 代表永不过期） |
| 6 | 7 | 过期前多少天提醒用户改密码 |
| 7 | 空 | 账号失效宽限期 |
| 8 | 空 | 账号失效日期 |
第二字段的哈希串里藏着不少信息：以$6$开头是 SHA-512，$5$是 SHA-256，$2y$是 bcrypt。密码哈希算法在/etc/login.defs文件里可以全局配置。出于安全考虑，新系统上我一般把加密算法调成SHA512或更高级别，并建议管理员开启密码过期策略，避免账号长期使用同一个密码。
还要提一个排查故障时常见的现象：第二字段如果是一个!或*，表示该账号密码被锁定，无法用密码登录。!通常是你用passwd -l锁定后的标记，*则常见于那些本来就不允许登录的系统账号。看到这类账号不要急着删，很多是系统服务自带的，删错了会导致服务起不来。
3.3 /etc/group 与 /etc/gshadow：组的成员关系网
/etc/group是组信息的核心文件，格式跟 passwd 很像，一行一个组，冒号分隔 4 个字段：
dev:x:1001:alice,bob,carol字段分别是组名、组密码占位符（同样有加密版本放在 gshadow）、GID、组成员列表（这里的成员是附加组关系，主组成员不会列在这里）。
注意上面那行里的 alice、bob、carol 都是通过usermod -aG加进去的附加组成员。文件里每行的最后一个字段正是附加组关系的“最终落点”。修改组成员可以直接编辑这个文件，但我强烈建议不要手动改，因为稍有不慎漏了冒号或写错用户名，可能导致该组里所有成员关系失效。用gpasswd -a username group这种专用命令更安全。
/etc/gshadow很少被关注，但它管着组密码和组管理员这些特殊功能。大多数场景下你根本用不到组密码，只需要知道有这么个文件、权限比 group 更严格即可。如果你是通过 NIS 或 LDAP 做集中认证，这个文件可能还会有更多门道，不过那属于企业级目录服务的范畴，这里先不展开。
3.4 用户创建时的默认参数：/etc/default/useradd 与 /etc/login.defs
每次用useradd创建新用户时，系统并不全靠命令参数生成账号，很多默认值来自配置文件。/etc/default/useradd定义了新用户的家目录基准路径、默认 Shell、创建用户时是否同时建主组等参数；/etc/login.defs则管理 UID/GID 起始范围、密码过期策略、是否创建邮箱目录等全局设定。
我建议新手先看一遍这两个文件再动手加用户，不然很可能出现这种情况：你用useradd建了个用户，结果它的 Shell 是/bin/sh（精简系统的默认），你没注意到，后面执行某些需要 bash 特性的脚本时各种报错，又排查半天。
grep -E '^(PASS_MAX_DAYS|PASS_MIN_DAYS|UID_MIN|CREATE_HOME)' /etc/login.defs输出示例：
PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 UID_MIN 1000 CREATE_HOME yes这些参数告诉我：密码默认永不过期，普通用户 UID 从 1000 开始分配，创建用户时默认建家目录。生产环境上我一般会把PASS_MAX_DAYS改成 90，让密码每年至少换 4 次；CREATE_HOME保持 yes，避免用户登录后没有家目录导致 shell 环境异常。
4. 实操过程中最常用的命令组合：从入门到日常巡检
4.1 用户管理三件套：useradd、passwd、userdel
创建用户的推荐姿势是用命令参数明确赋值，而不是全凭系统默认。我习惯这样写：
useradd -m -d /home/dev01 -s /bin/bash -u 1500 -G wheel,developers dev01参数含义拆开说：
-m：同时创建家目录，这是新手的头号坑。忘了加 -m，账号建出来了但登录后没有家目录，一堆程序会因为写不了~/.bash_history、~/.cache之类路径而出诡异问题-d /home/dev01：指定家目录路径。这个参数最好和 -m 一起用，保证目录路径和账号信息写入的是同一个位置-s /bin/bash：指定登录 Shell。如果你不想让这个用户可以登录，就设成/sbin/nologin或/usr/sbin/nologin-u 1500：手动指定 UID，常用于需要跨服务器保持相同 UID 的场景（比如 NFS 共享目录，UID 不对应会直接表现为文件属主乱套）-G wheel,developers：把用户加入附加组，wheel 组的含义因发行版而异，很多系统里它默认拥有 sudo 权限
建完账号立刻设置密码：
passwd dev01交互式输入两遍密码即可。如果你想在脚本中非交互式设置密码，可以用下面这种方式：
echo 'YourStrongPass123' | passwd --stdin dev01注意--stdin这个参数在部分发行版（比如某些版本的 Debian/Ubuntu）不受支持，我更建议用 Python 的 crypt 模块生成加密串，然后直接写 shadow 文件，或者用 chpasswd 命令。脚本里设置初始密码这类操作务必备注清楚这是什么权限级别的操作。
删除用户同样要留心：
userdel -r dev01-r会同时删除家目录和邮件池。但如果这个用户之前运行过某些服务，进程还在跑，直接删用户会导致一堆文件变成“无主”状态，也就是 UID 没有了，但文件系统里还躺着大量以那个 UID 为属主的文件。所以我的建议是先杀掉相关进程或彻底确认用户没有关键服务依赖，再执行 userdel -r。
4.2 组管理的实用操作：groupadd、groupmod、gpasswd
建组的命令比较简单：
groupadd -g 2600 devteam-g手动指定 GID。日常管理里更常用的是 gpasswd 系列：
gpasswd -a dev01 devteam # 把 dev01 加入 devteam 组 gpasswd -d dev01 devteam # 把 dev01 从 devteam 组移除 gpasswd -A dev01 devteam # 指定 dev01 为 devteam 管理员组管理员可以自行管理组成员，这在团队协作时很好用——不用每次都麻烦 root 来加人。组管理有个很微妙的问题：用户修改附加组后，立即生效吗？答案是不一定。用户在登录会话里持有的组 ID 列表是在登录时缓存下来的，如果你把一个用户加进 docker 组，而对方已经登录着，他必须重新登录（或者执行newgrp docker刷新会话）才能获得 docker 组的权限。但你在 root 会话里执行su - username重新切换的话，也会刷新。
4.3 修改用户属性的核心命令：usermod 的参数速查
日常运维中，改用户属性比创建新用户更频繁。usermod的常用参数我整理了个表：
| 参数 | 作用 | 实际场景 |
|---|---|---|
-l 新名字 旧名字 | 修改用户名 | 用户改名，但注意 UID 不变 |
-d /home/newhome | 修改家目录路径 | 迁移数据后需要同步路径 |
-m -d | 搬家并移动旧目录内容 | 配合 -d 用，旧家目录内容会转移到新路径 |
-s /sbin/nologin | 修改登录 Shell | 禁止某用户登录系统 |
-G group1,group2 | 覆盖附加组列表 | 危险操作，会移除原有所有附加组，只保留指定的 |
-aG group | 追加附加组 | 安全写法，保留原有附加组并追加新组 |
-L / -U | 锁定 / 解锁账号 | 临时禁止或恢复某用户登录 |
这里我最想强调的就是-G和-aG的区别：-G是“用这一组替换原来的附加组”，-aG是“在原来基础上增加”。我见过不止一次有人想给用户加一个 docker 附加组，结果用了-G docker，把用户从几十个组里剥离出去，差点把用户的环境搞崩。专线运维必须记住：没加 -a 的 -G 等于全部重来。
4.4 提升权限的两种方式：su 与 sudo 的最佳实践
提权操作是另一个日常高频场景。su - root会完整切换成 root 身份，加载 root 的环境变量；sudo command则是临时以 root 身份执行单条命令。生产环境我强烈建议禁用 root 直接 SSH 登录，运维人员全部通过普通用户 + sudo 的方式来做事，理由很直白：sudo 的操作有审计日志，出了事能追溯到人；su 切到 root 后，日志里只看到一条 su 记录，后面谁敲了什么命令，全靠 bash history 自觉。
sudo 的权限规则写在/etc/sudoers文件里，必须用visudo命令编辑，因为这个命令会做语法校验，避免写错造成 sudo 完全不可用。常见配置：
dev01 ALL=(ALL) ALL这行的意思是 dev01 可以在任何主机（ALL）上以任何用户身份（ALL）执行任何命令（ALL）。更克制的写法是只允许某些命令：
dev01 ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/vim /etc/nginx/nginx.conf这样 dev01 只能重启 nginx 和改 nginx 配置，即使密码泄露，攻击者能造成的破坏也局限在这两个命令之内。
5. 常见问题与排查技巧实录：实战中踩过的坑
5.1 用户突然无法登录？先查这三个地方
这类问题我处理过很多次，排查顺序基本固定：
第一，确认密码是否过期。看/etc/shadow里第三、第五字段：如果第五字段是 90 而第三字段距今快 90 天了，密码可能已经过期。chage -l username可以快速查看密码时效信息。处理办法是chage -d $(date +%Y-%m-%d) username强制更新密码时间戳。
第二，检查 Shell 是否被改成 nologin。grep username /etc/passwd看最后一个字段。如果改坏了，usermod -s /bin/bash username恢复。
第三，确认账号是否被锁定。shadow 里第二字段以!开头就是锁了，passwd -u username解锁。
5.2 文件属主显示成数字？这是 UID 失联了
你可能会遇到ls -l输出中属主列不是用户名而是一串数字的情况。比如：
-rw-r--r-- 1 1500 2600 1234 Jun 10 10:00 data.log这说明系统在 /etc/passwd 和 /etc/group 里找不到 UID 1500 对应的用户和 GID 2600 对应的组。常见原因是那个用户被删了但文件还留着，或者是 NFS 挂载的共享目录里，远程服务器上的 UID 在本机不存在。处理方法：要么找到原用户的 UID 重建账号（useradd -u 1500补上同名账号），要么chown把文件转移给现有用户。不要以为是系统坏了，这只是身份映射表里缺了条目。
5.3 加进组了但权限还是不够？重新登录刷新会话
前面提过会话缓存的组 ID 问题。你刚把一个用户gpasswd -a dev01 docker加进 docker 组，他却发现docker ps还是报permission denied，十有八九就是没重新登录。可以用id username查看组信息是否已更新，如果命令输出了新组但实际执行还是失败，让用户退出会话重新登录，或者临时执行su - username再退出。
5.4 sudo 配置错了导致 sudo 本身也废了？用 pkexec 或直接 root 修复
如果/etc/sudoers语法写错，导致所有用户都跑不了 sudo，系统会陷入一种“管理员进不去”的尴尬状态。不要慌，如果系统装了 polkit，可以直接通过pkexec visudo以图形授权方式提权修复。如果 pkexec 也不可用，只能重启进单用户模式（在 GRUB 引导参数里加single）以 root 身份修复文件。脚本化修改 sudoers 前，务必先执行visudo -c做语法检查。
5.5 批量创建用户与同步 UID/GID 的脚本思路
几十台服务器需要同一批用户的场景，手动敲命令显然不现实。比较稳妥的做法是：在一台基准服务器上建好所有用户和组，然后打包/etc/passwd、/etc/shadow、/etc/group、/etc/gshadow四个文件复制到目标机器上，或者基于 LDAP/SSSD 做统一认证。复制时注意检查各服务器版本一致性和文件格式兼容性，否则可能出现某些账号无法登录。
for u in dev01 dev02 dev03; do useradd -m -s /bin/bash "$u" echo "$u:InitialP@ss123" | chpasswd done这种批量建号脚本在初始化测试环境时很好用。但放到生产环境，我会提醒注意：初始密码一定要求首次登录强制修改。方法是用chage -d 0 username，这样用户下次登录系统会强制要求改密码——这个细节能大幅降低初始密码泄露导致的风险。
5.6 一个容易忽略的权限细节：umask 决定新文件的出厂权限
最后聊一个和用户与组管理强相关但又最容易被忽略的参数：umask。它决定了新创建文件的默认权限。普通用户默认 umask 一般是 0022，所以新建文件权限是 644（rw-r--r--），新目录是 755（rwxr-xr-x）。如果改成 0027，则文件是 640 目录是 750。这意味着，即使你把一个目录的属组设为 dev，组成员能不能读里面新建的文件，不仅看目录权限，还要看创建者自己的 umask。跨部门共享目录时，我通常会把共享目录的 umask 调成 0002，并设置 setgid 位，确保新文件自动继承目录的属组：
chmod g+s /srv/shared这条命令让该目录下新建的文件组归属自动变成目录的属组，而不是创建者的主组。配合正确的 umask，共享协作才不会频繁出现“其他人读不了我建的文件”这种问题。
6. 实操心得与扩展方向
内容讲到这里，用户与组管理的骨架基本立起来了。我在实际使用中的体会是：不要把用户和组管理看成“敲几条命令”的事，它背后是一套关于边界与权限的思维方式。你每一次创建用户、分配组、设置 sudo 规则，都是在画圈——圈定了谁能碰什么、不能碰什么。圈画得越细，系统越安全；圈画得越粗，管理越省事，但风险也越大。
最后再分享一个我沿用多年的检查清单，每次排查权限相关故障时按顺序过一遍：
- 先看用户身份：
id username- 再看进程身份：检查进程的 UID 和 GID
- 然后看文件权限：
ls -l 和 stat确认属主属组和权限位- 检查目录权限：文件所在路径每一层目录的可执行权限
- 确认是否涉及特殊权限位：suid、sgid、sticky
- 最后查 umask、ACL、SELinux（如果启用了）
这个顺序能解决九成以上的权限疑难杂症。等这套东西熟练了，你完全可以再往深处走：学习 ACL 访问控制列表做精细授权、探索 PAM 模块定制认证流程、甚至搭建 LDAP 统一身份认证平台。但不管掌握多少高级功能，根基始终是用户、组、权限这三个基本概念。把这几个点吃透，Linux 系统的其他模块学起来都会顺很多。
