平时给项目组开账号最常看到的一种现象就是初级运维手里攥着 root 密码需要哪个同事登录服务器就直接给 root。等服务器被删库、被改坏配置之后大家才想起来 Linux 其实有一套完整的用户工作组管理机制而“什么人用什么身份登录、能碰哪些文件、能做哪些操作”恰恰是一个运维最基本的基本功。这一篇把 linux 基本命令里关于用户和用户组管理的核心命令一次讲透从底层概念到实战排错适合刚入门想系统理解权限体系的读者也适合干了一段时间但一直靠背命令混日子的运维系统补一遍。1. 先把用户和用户组的底层逻辑讲透1.1 为什么 Linux 非要搞“多用户”这套东西很多人不理解我单机用一台 Linux就我一个人登录用户和组有什么好管理的这个问题的答案要回到 Linux 设计之初的哲学它从诞生起就是给多用户共用的系统设计的。服务器上同时跑着 Web 服务、数据库、定时任务、好几个项目组的脚本每个服务或进程都需要一个身份去运行。没有用户隔离一个进程就能随便读写另一个进程的文件没有组的概念想让一拨人协作访问同一批文件就得逐个用户授权管理成本直接爆炸。用户和组解决了三件事第一是身份隔离每个人的家目录、个人配置是独立的第二是权限最小化服务进程用专用账号运行不给你普通用户访问系统文件的权限第三是责任可追溯出问题的时候可以通过进程的用户身份、文件属主去定位是谁操作了什么。1.2 三张核心数据库文件用户和组的信息不是凭空存在内存里的它们固化在三个文本文件里。理解这四个文件你就理解了一大半用户管理的底层原理。/etc/passwd 是用户账户数据库每一行代表一个用户字段用冒号分隔。以 root 为例root:x:0:0:root:/root:/bin/bash七个字段的含义分别是用户名、密码占位符x 表示真正的密码在 shadow 里、UID、GID、备注信息、家目录、登录 Shell。注意这个文件默认所有用户可读所以密码绝对不能放在这里老系统里直接存加密密码早就淘汰了现代表现就是那个 x 占位符。/etc/shadow 是密码数据库只有 root 和有需要的程序能读。一行分成九个字段testuser:$6$rounds656000$xxx...:19123:0:99999:7:::从左到右分别是登录名、加密后的密码、最后一次修改密码距离 1970年1月1日的天数、最短修改间隔、密码最长有效期、过期前警告天数、账户不活动天数、账户失效日期、保留字段。后面讲 chage 命令时会用到这些字段。/etc/group 是用户组数据库devops:x:1002:alice,bob,carol四个字段是组名、组密码占位符基本用不上、GID、组成员列表。这里的成员是“额外成员”也就是把这个组作为次要组的用户每个用户自己在 /etc/passwd 里的 GID 才是他的主组。1.3 权限位是怎么和用户组联动起来的文件权限位总共十位第一位是文件类型后面九位分成三组所有者、所属组、其他用户。每组三个字符 rwx对应读、写、执行。数字表示法里 4 读、2 写、1 执行三组相加就是 644、755、775 这种我们天天见的写法。判断一个用户能不能操作某个文件系统是这样走逻辑的先看进程的用户是谁如果这个用户正好是文件所有者和属主就匹配第一组权限如果不是所有者但用户的某个组主组或额外组正好等于文件的所属组就匹配第二组权限两个都不沾就落到第三组其他用户权限。这就是用户和组在权限系统里最核心的作用。注意判断顺序是“所有者优先于所属组优先于其他”一个用户即使同时是文件所有者和所属组成员系统也只会采用所有者那一组权限不会取组权限中更大的值。这个坑在后面排权限问题时经常出现。2. 用户账号管理从创建到删除的完整链路2.1 useradd 创建用户的默认值与自定义参数创建用户最常用的是 useradd但新手经常遇到“建了用户却登录不了”“家目录不存在”这种问题根源是不清楚 useradd 的默认行为。在多数现代发行版上useradd 会顺带创建家目录并复制一批骨架文件比如 /etc/skel 里的 .bashrc。在有的精简系统上默认不会创建家目录这就导致 useradd testuser 之后登录直接进到 /还要手动 mkdir 和 chown非常别扭。一个可靠底线式的创建命令长这样useradd -m -d /home/testuser -s /bin/bash -c 测试账号 -u 1501 -g devops -G wheel testuser参数含义如下参数作用备注-m家目录不存在时自动创建强烈建议写上-d指定家目录路径一般用默认路径也行-s指定登录 Shell不写时用系统默认可能有差异-c备注信息建议写上谁在用这个账号-u手动指定 UID多台服务器同步权限时很有用-g指定主组可以用组名或 GID-G指定额外组逗号分隔注意是覆盖不是追加后面细说创建完用户后需要立刻设置密码否则账号处于锁定状态。设置密码用 passwdpasswd testuser交互式输入两遍就行。脚本化场景下RHEL 系支持echo 密码 | passwd --stdin testuser但 Debian 系不支持 --stdin这时候可以改用chpasswdecho testuser:你的密码 | chpasswd我个人很反对在命令行直接敲明文密码因为 shell 历史里会留下记录。更稳的做法是在安全环境里交互式设置或者用密钥登录跳过密码环节。2.2 passwd 与 chage密码策略配置Linux 里 passwd 不只手改密码。几个高频场景passwd -l testuser锁定用户效果是在 /etc/shadow 里密码字段前加感叹号用户即使有密码也登不进去。passwd -u testuser解锁。passwd -d testuser删除密码只留空密码一般是给程序用的特殊账号不建议给人工账号用。passwd -e testuser让密码立即过期等价于 chage -d 0。密码策略更多依赖 chage 命令。比如要求用户 90 天改一次密码提前 7 天警告最短间隔 5 天chage -M 90 -m 5 -W 7 testuser chage -l testuserchage -l会输出密码过期时间、账户过期时间等完整信息。强制新账号第一次登录必须改密码这是最常用的初始化手段chage -d 0 testuser这样做之后用户第一次登录系统会直接跳出“必须更改密码”的强制提示直到设置完新密码才出现正常 shell 环境。批量处理很多账号时这比挨个要求改密码可靠得多。2.3 usermod 修改用户属性时的翻车现场用户建好之后要调整属性用 usermod。常见的操作usermod -s /sbin/nologin testuser # 改成禁止登录 usermod -L testuser # 锁定账号 usermod -aG docker testuser # 追加到 docker 组 usermod -g devops testuser # 修改主组usermod 有一个特别容易翻车的点usermod -d只是修改 /etc/passwd 里的家目录字段不会搬运原来的文件。假设有个用户原来家目录是 /home/old他的 .bashrc、.ssh 全在里面你执行了usermod -d /home/new testuser结果就是该用户下次登录时系统按 /home/new 去找家目录里面啥都没有连 bash 提示符都可能进到临时目录密钥登录直接失效。正确做法是先把文件搬过去再改字段mkdir /home/new cp -a /home/old/. /home/new/ chown -R testuser:testuser /home/new usermod -d /home/new testuser另一个翻车点是改 UID。同一个文件在系统里的归属是按 UID 记录的不是按用户名。你把 testuser 的 UID 从 1501 改成 2001那他原来所有的文件属性还是 1501而这些文件从系统角度看属于一个根本不存在的账号显示成 1501 的数字实际访问权限全乱了。所以没有充分把握不要乱改 UID真改的话改完必须全盘 find 一遍把 UID 对应文件都 chown -R 掉。2.4 userdel 删除账号时做没做“善后”删除用户是 userdel但它默认并不同时删家目录和邮件池等文件。userdel testuser # 只删账号 userdel -r testuser # 删账号并删除家目录和邮件池新手习惯直接加 -r但这有隐藏风险如果这个用户之前跑过定时任务、部署过应用那些文件可能散布在 /opt、/data、/var/www 下面-r 参数根本不会碰它们。删除后再去看这些目录会发现一堆数字 UID 的“孤儿文件”后续新账号还可能撞到同名属性非常难查。比较稳的删除流程是先查后删find / -user testuser -type f 2/dev/null /tmp/testuser_files.txt userdel -r testuser # 根据清单决定保留、迁移还是删除删除前还要确认这个用户是不是其他文件的关键属主、是不是某个服务账号。生产环境里最忌讳随手 userdel -r。3. 用户组操作重点理解“组”在协作中的价值3.1 groupadd 与 groupdel 的基本规则创建组很简单groupadd devops groupadd -g 2001 devops groupadd -r sysgroup # 创建系统组GID 一般在系统范围内指定 GID 的意义在于多台服务器要同步相同的组结构时GID 必须一致。组名随便改没关系但组内文件权限认的是 GID组名不一致还能靠 GID 认出来。删除组用 groupdel。有个常见报错[rootserver ~]# groupdel devops groupdel: cannot remove the primary group of user testuser意思是还有用户的主组是 devops必须先把这个用户的主组改走或删除用户才能删除这个组。这是保护机制防止留下 GID 悬空。额外组成员被自动清掉这个不算阻碍删除主要组用户才是硬条件。另外如果某些文件的所属组是要删的这个组删除之后文件会显示成一个不存在的 GID同样会留下孤儿属性删除前也应该全局扫一遍。3.2 gpasswd 管理组成员与组密码组成员增删有两条路线usermod -G 和 gpasswd。日常协作场景里gpasswd 更直观gpasswd -a alice devops # 把 alice 加进 devops 组 gpasswd -d alice devops # 把 alice 移出 devops 组 gpasswd -A alice devops # 指定 alice 为 devops 组管理员组管理员区别于 root 的地方是组管理员可以在这个组里增删成员但不需要 root 权限。这对项目组自行维护组内人员流动非常有用可以避免所有变更都来烦运维。gpasswd 不带参数直接运行是设置组密码。组密码配合 newgrp 命令使用如果你不是某个组的成员但知道组密码可以用newgrp 组名临时切换当前进程的有效组身份输入组密码后就能获得这个组的权限。不过实际操作中组密码用处不大依靠 sudo 和组成员管理就能覆盖绝大多数场景。3.3 usermod -G 的覆盖行为与“追加”陷阱这是新手踩得最多的组管理坑。usermod -G 的语义是“将用户的额外组设置为指定列表”不是“追加”。比如usermod -G docker testuser执行完之后testuser 如果之前还挂在 devops、wheel 组这些组的成员身份全部被清掉只剩 docker。更危险的是在很多系统上普通用户还可能挂在一些默认组下这样一覆盖可能连基本权限都受影响。如果你本来就想追加最稳的做法是先看当前组再带上所有要保留的组一起写groups testuser # 输出 testuser : testuser docker usermod -G testuser,docker,devops,wheel testuser或者干脆用 gpasswd -a 逐步追加。我个人偏好 gpasswd 语法可读性高也不容易把别人踢出组。3.4 组成员身份刷新新开会话才生效修改组成员之后用户当前的登录会话不会自动刷新组信息。用户可能明明已经加进组了但在当前终端里 id 一下还是看不到新组写新目录照样 Permission denied。原因在于用户登录时初始化进程从内核拿到一组凭证并保存起来后续 fork 的子进程都继承这份凭证。usermod/gpasswd 改的是数据库文件已经登录的会话不会主动感知。解决方法是让用户退出重新登录或者建立一个新会话su - testuser通过这种重新认证的方式刷新凭证。自动化脚本场景下如果需要在一次操作中修改组并立刻执行可以把命令拆成两个阶段或者用 ssh 重新连接。4. 查询与审计用户信息4.1 id 命令的完整输出解读排查权限问题第一件事永远是 id。执行id testuser输出示例uid1501(testuser) gid1002(devops) groups1002(devops),10(wheel),993(docker)这里有三层信息UID、主组 GID、额外组列表。注意文件和进程的身份判断按这个输出为准不要凭记忆。还可以只取单个值id -u testuser # 只看 UID id -g testuser # 只看主组 GID id -Gn testuser # 只看所有组名空格分隔 id -nG testuser # 和上面一样某些系统用 -nG脚本里经常用到id -u username判断用户是否存在或者权限等级。如果命令输出no such user说明用户在本地数据库根本不存在。4.2 通过 groups 和 getent 排查用户组归属groups 命令比 id 更直白只显示组名groups testuser # testuser : testuser devops docker wheel注意groups 查询输出的是 /etc/group 里的静态信息。如果系统接了 LDAP、NIS 这类集中认证服务本地文件查不到全部数据这时要用 getentgetent passwd testuser getent group devopsgetent 会按照系统数据库的优先顺序包括本地文件、NIS、LDAP 等去查返回的是真实生效的数据。排查“明明 /etc/group 里有怎么 groups 查不到”这类问题先分清查的是本地文件还是全量数据源再确认是不是缓存或会话过期。4.3 权限亲和验证ls -l 和 stat 怎么配合用ls -l 是最常用的但有时不够。比如ls -l /data/project_a # drwxrwsr-x. 3 root devops 4096 ...输出里的devops是文件所属组。表面看该组有 rwx 权限但用户 alice 写文件还是被拒这时单看这一层不够。要逐层检查路径上的每一级目录namei -l /data/project_a/subdir stat -c %n %U %G %a /data/project_a /data /现实里最常见的权限问题恰恰不是文件本身没权限而是父目录或更上级目录缺少执行权限x。也就是说用户根本没权限“走”到那个目录。namei 一次性把路径上每一级目录的用户、组、权限都列出来排查效率极高。stat 可以快速看属主属组和八进制权限位也能顺带看到 setgid、粘滞位这些额外标记。5. 多用户协作场景的权限模型搭建与排错5.1 共享目录模型setgid 组权限的搭建假设某项目组有 alice、bob、carol 三人需要在一个公共目录里协作文件要彼此可见、可编辑其他人一律不能动。第一步是建组groupadd project_a gpasswd -a alice project_a gpasswd -a bob project_a gpasswd -a carol project_a然后是建目录并设置属组与权限mkdir -p /data/project_a chgrp project_a /data/project_a chmod 2770 /data/project_a这里 2770 中的 2 是关键它设置 setgid 位。setgid 作用在目录上的含义是所有在目录内新建的文件和子目录继承目录所属组而不是创建者自己的默认主组。如果没有这个位用户在目录里 touch 出来的文件属组是用户自己的主组别的项目组成员即使同在一个目录也无法互相编辑。设置之后还需要配合继承的权限掩码否则新建文件默认只有 644组成员只能看不能改。全局修改 umask 有副作用更推荐单独给目录设置 ACL 继承或者要求组内成员把 umask 设成 002。脚本自动化方式是在 /etc/profile 或各用户的 ~/.bashrc 里设置umask 002这样新建文件的权限变成 664新建目录变成 775组成员可以正常写外界文件默认只有读写权限。配合 setgid 位整个目录的组协作就顺了。5.2 粘滞位在共享目录中的必要性共享目录如果允许组内每个人都能写还要防止成员 A 删掉成员 B 的文件这时候要引入粘滞位。你只要看一眼 /tmp 的权限就明白ls -ld /tmp # drwxrwxrwt. 21 root root ...最后一位是 t对应八进制权限的 1000 位所以 /tmp 的完整权限写出来是 1777。粘滞位的作用是在这个目录里只有文件属主、目录属主、root 能删除或重命名文件其他用户即使有写权限也不能随意动别人的文件。如果项目组要求目录内所有组员都能创建文件但不能互相删除可以把权限设定为chmod 1770 /data/project_a1770 粘滞位 1000 属主 rwx 7 属组 rwx 7 其他 0。项目成员能写能读行动受限只体现在“删别人的文件”这件事上。对五六个人合用一个部署目录的场景这个配置非常实用。5.3 实战排查新增组员就是没权限有一次同事报障“我把新同事的账号加进 devops 组了他也重新登录了怎么还是写不了共享目录”我过去第一件事就是查 idid 新同事 # uid1601(newuser) gid1601(newuser) groups1601(newuser)这里就能看出问题新用户在 devops 组里压根不存在gpasswd -a 操作在另一台服务器上做的这台服务器没同步。查清这个根因之后就是在目标机器上补加组成员。还有一次是用户确实在 devops 组里目录也是 2770setgid但写文件还是失败。用 namei 一看问题落在 /data 这层namei -l /data/project_a # / drwxr-xr-x root root # data drwx------ root root # project_a drwxrwsr-x root devops/data 的权限是 700除了 root 没人能进入。我之前只改了目标目录权限忘了处理父目录。这种路径权限问题用肉眼很容易漏掉。用 namei 逐层看哪一层卡住一目了然。这个坑的实际发生频率比想象中高得多尤其是根目录是用户 home 目录、单独分区挂在某路径下这类情况。排查权限问题的标准顺序我现在基本固定为id 看身份 → groups 或 getent 确认组成员 → namei 看路径 → ls -ld 看目标目录 → 测试实际写入。每一步都能快速剔除一批可能原因不要上来就凭感觉 chmod 777。5.4 几条经得起检验的经验账号管理做得好的服务器日常运维会轻松非常多。我自己的几条体会分享给读者一是尽量别用一个万能 root 账号跑所有操作。日常登录用个人普通账号需要提升权限时用 sudo配上精确到命令级别的 sudo 规则安全和审计就都有了。二是用户主组尽量和业务一一对应一人一组容易造成共享目录权限模型复杂几个项目组共用服务器时尤其明显。组的设计比用户设计更影响权限模型的复杂度多花点时间在组划分上是值得的。三是改任何东西之前先看一眼“后果”——userdel 是不是带 -rusermod -G 是否会覆盖chgrp 会不会把关键文件的属组改乱。四是服务器多的时候用户和组数据同步问题要提前规划本地手工添加只能撑单机场景接集中认证之后 getent 才是金标准。五是删账号前全局扫一遍文件归属宁可多花五分钟也不要在三个月后被一堆孤儿文件坑到。用户和组的命令本身并不多难的是理解权限模型和养成操作前检查的习惯。能用普通用户解决的问题就不用 root能分组的操作就别给个人授权能走审计的命令就别直接粗暴地改权限。这套思路理顺之后再回看 useradd、groupadd、id、chmod 这些命令你会觉得它们不再是一个个孤立的知识点而是一整套保护服务器安全运行的协作机制。