1. 为什么Linux要搞用户和组这套东西很多刚接触Linux的人都会问一个问题为什么Windows下我开机就能用Linux却非要分什么用户、组、权限直接用root不行吗先说结论root确实能做所有事但你不会想用root干所有事。Linux沿用了Unix几十年的多用户设计哲学这套体系的核心目标是权限隔离——让每个进程、每个文件都明确归属到某个用户和组谁能读、谁能写、谁能执行系统里每个资源都有清晰边界。举个生活化的例子一个公司里普通员工只能进自己的工位和公共区域财务室、机房的钥匙只有特定部门有。如果所有人都拿万能钥匙任何一台电脑都能访问公司所有资料那内部出问题只是时间问题。服务器也一样——如果所有应用都用root跑一个Web服务的漏洞被利用攻击者直接拿到整台服务器的最高控制权连数据库备份文件都能顺手带走。而如果Web服务以普通用户的身份运行漏洞被利用后攻击者能碰到的只有那个用户权限范围内的东西伤害面小很多。这也就是我会把用户与组管理称为“Linux系统安全的地基”——权限规划做不好后面所有安全加固都白搭。不管你是刚装好一台CentOS想搭开发环境还是在公司接手一台多部门共用的生产服务器或者只是给自己折腾NAS、树莓派这类小玩具搞明白用户和组的管理逻辑都是绕不开的第一步。这篇内容我会从底层原理讲到具体命令把用户、组、权限、以及sudo授权这几块串起来。不是单纯背命令而是讲清楚每个操作背后的逻辑——你理解了为什么这么设计后面遇到奇怪的问题自己就能推断出来。2. 核心概念串讲用户、组与权限到底怎么协作2.1 用户是身份的起点组是权限的集合Linux里的“用户”并不只是登录时那个用户名。每个用户对应一个UID用户ID内核实际只认数字不认名字。用户名只是给人看的映射而已。每个用户的文件、进程都打着这个UID的标记内核判断“这个文件能不能删”“这个进程能不能杀”本质是比对UID和文件权限位。“组”Group则是把多个用户圈在一起的权限集合。为什么要多一层组想象一台服务器上有开发A、开发B、开发C三个同事他们都需要读写某个项目目录。如果你按用户逐个授权每加一个用户就要改一次文件的ACL或权限位非常啰嗦。更优雅的做法是建一个dev组三个人都加入dev组只要给目录设置组读写权限后续来了开发D只需要把他加进dev组就完事——这就是组存在的意义让权限管理从“一对一”变成“一对多”。Linux还规定每个用户必须有一个主组primary group。用户新建文件时文件的属组默认就是自己的主组。一个用户还可以同时加入多个附加组supplementary groups。区分主组和附加组的意义在于主组决定你新建文件的默认属组附加组让你能同时拥有多个领域的访问权限。比如一个用户主组是自己的私有组附加组有docker组因此能用docker命令、wheel组因此能sudo三者互不冲突。2.2 权限位的阅读方法rwx不止是三个字母权限位的本质是三组“rwx”的组合。第一组是属主owner权限第二组是属组group权限第三组是其他所有人others权限。r代表可读4w代表可写2x代表可执行1数字权限就是这三者累加。这里有个很多新手踩过的坑目录的x权限和文件的x权限含义并不完全一样。对文件来说x是“能执行”对目录来说x是“能进入”——没有目录的x权限哪怕你有r权限能列出目录内容也进不去这个目录人家叫“扫描权限”。同样目录的w权限也不是“能改文件内容”而是“能在目录里新建、删除、重命名条目”。这也是为什么对一个共享目录通常要同时给rx否则别人能看目录列表却进不去。顺带说一个常见困惑普通用户A能不能删除root创建的、权限是644的文件关键不在文件本身而在文件所在的目录。如果目录对用户A有wx权限那A可以在目录里删除任何条目即使那个文件属于root、权限只读。很多“共享目录被别人误删”的事故就是这么发生的。这个细节在项目协作场景特别重要——你需要区分“文件本身可写”和“目录允许删除”是两回事保护文件往往要保护它所在的目录而不是文件本身。2.3 新建用户会导致哪些默认文件出现当你执行useradd还附带创建家目录时系统会从/etc/skel目录拷贝一份模板文件到新用户的家目录里。这个/etc/skel里通常有.bashrc、.profile这类shell配置文件。很多人不知道这个目录是可以自定义的——你可以往/etc/skel里放一个欢迎脚本、一个项目规范文档、甚至预设好的.vimrc以后每次新建用户都会自动带上省去逐台机器配置的重复劳动。我自己管理服务器时会把一些统一的别名、环境变量template也放进去新来的同事账号一建好基础环境直接就是齐的。3. 配置文件逐行解读用户信息到底存哪了3.1 /etc/passwd与/etc/shadow的分工大多数Linux发行版的用户信息分散在两个核心文件里。先看/etc/passwd每一行对应一个用户用冒号分隔成7个字段username:x:1000:1000:姓名注释:/home/username:/bin/bash第一个字段是用户名第二个字段在早期Unix里存密码哈希现在统一是x表示真正的密码放在/etc/shadow里这是出于安全考虑/etc/passwd需要被世界可读以便各种工具查询用户信息密码不能跟着暴露第三个字段是UID第四个字段为主组GID第五个字段为注释信息通常存姓名或描述第六个字段是家目录路径第七个字段是登录shell。如果第七个字段是/sbin/nologin代表这个用户被禁止登录系统只能用来运行服务或占位——很多系统服务账户都是这种类型。/etc/shadow只有root可读每一行同样用冒号分隔核心是第二字段的密码哈希。密码哈希前常有不同前缀$6$开头是SHA-512$y$是近年流行的yescrypt部分新发行版$2y$是bcrypt。后面的字段还包括密码最后修改时间、过期策略、宽限期等等。实际上当你执行passwd修改密码改的其实是shadow文件。为什么一定要用shadow文件因为早期密码直接存在passwd里那个文件可能被普通用户读取来离线爆破。把密码挪到只有root能读的shadow里攻击面立刻小很多。这是Linux安全设计演进的一个典型例子。3.2 /etc/group和/etc/gshadow组信息对应/etc/group一行四个字段组名、组密码通常也是x、GID、组成员列表。组成员列表用逗号分隔附加成员主组成员不写在这里——因为/etc/passwd里第四字段那个GID已经标明了每个用户的主组。这也解释了为什么你明明把用户加进某个组用id命令能看到但/ect/group里不一定直接有那个名字因为它在passwd里通过主组GID关联。/etc/gshadow则类似shadow之于passwd存放组的密码和组管理员信息。平时给普通组设密码的场景较少但涉及建共享目录、临时授权某些用户访问一个组的资源时组密码能充当一道门槛。多用户协作的组里这个功能还是偶尔会用到的。修改这些文件时的铁律必须用vipw和vigr。直接vim编辑容易出格式错误而且vipw会加锁防止多人同时改文件改完还会提示你同步shadow。这类文件一旦字段错位可能导致某个用户无法登录、甚至系统某些服务起不来。我在生产环境见过有人手滑改了passwd里UID结果用户所有文件归属全部错乱——真是灾难现场。4. 用户与组管理核心命令实操4.1 创建用户的完整决策链创建用户的命令在不同发行版有差异。基于Debian的系统如Ubuntu通常有adduser这个交互式包装脚本它会自动创建家目录、设置密码、生成随机UID而CentOS/RHEL/Fedora则常用useradd这个底层命令参数更灵活但默认行为需要自己把握。这篇文章以useradd为主线因为它的参数逻辑能帮你理解系统底层行为。我推荐创建用户时养成带完整参数的习惯不要裸敲useradd就完事useradd -m -d /home/zhangsan -s /bin/bash -c Zhang San -u 1005 -g zhangsan -G wheel,develop zhangsan逐个解释-m创建家目录。如果不加大部分发行版不会自动建家目录。-d指定家目录路径默认是/home/用户名一般不用改但特殊场景可指定到数据盘。-s登录shell默认可能是/bin/sh建议显式指定为/bin/bash否则交互体验很差。-c注释信息写个姓名或工号方便后面查id时辨认。-u手动指定UID。这个看场景有些公司有统一UID规划有些则让系统自动生成。如果你在同步多台服务器用户信息UID手工统一会省很多跨机同步的麻烦。-g主组必须预先存在。-G附加组可以多个用逗号分隔。把用户加入wheel组CentOS或sudo组Ubuntu就赋予了sudo权限这一步对常规运维人员来说几乎是刚需。用户创建之后紧接着要执行passwd zhangsan设置初始密码。这里有个实践技巧临时给一个人开账号时可以用echo 初始密码 | passwd --stdin zhangsanCentOS支持首次登录后强制改密。强制改密的做法是chage -d 0 zhangsan这样用户下次登录时必须先改密码否则什么都干不了。这对临时账号、外包人员账号特别有用——既给了访问能力又杜绝了初始密码被长期使用。4.2 批量创建用户的省力方案如果一个一个敲useradd太烦还有批量方案。这是我在迁移一批账号时用的方法先准备一个users.csv文件每行一个用户信息用for循环批量处理。while IFS, read -r user uid comment; do useradd -m -s /bin/bash -c $comment -u $uid $user echo 初始密码123 | passwd --stdin $user chage -d 0 $user done users.csv注意这不是“完全没有坑”的脚本实际用的时候还要加上判断比如用户是否已存在、张comment里是否有中文逗号等。但思路很重要运维工作中凡是超过5个用户的需求都值得用脚本而不是手工去敲。人手工操作一定会漏、会错脚本反而可重复、可审计。批量建组同理groupadd一个循环就解决了。4.3 用户修改usermod是瑞士军刀用户信息改了之后不需要删掉重建usermod就是干这个的。常见用法usermod -s /bin/nologin zhangsan # 禁止登录 usermod -G docker,lfs zhangsan # 覆盖附加组注意这会替换掉原有附加组 usermod -aG develop zhangsan # 追加附加组最关键的教训就在-G上。很多人想给用户加一个新组直接写-G docker结果用户本来在wheel组里的sudo权限瞬间没了。因为-G不是追加是替换。正确做法是每次追加都用-aG或者先usermod -G列出当前所有组然后再加上新组重新赋值。我吃过这个亏当时给一个同事加docker组没加-a把他的sudo权限带走了他当场一脸懵。所以强制自己形成一个肌肉记忆附加组修改永远用-aG不要用-G。锁定用户账号也有几个层级usermod -L或passwd -l锁定密码ssh密钥登录还能用如果开了。usermod -s /sbin/nologin禁掉shell登录但sftp这类依赖shell的也会被禁纯ftp不受影响。chage -E 2026-12-31设置账号过期时间到期自动失效。如果一个人离职了我建议的处置顺序是先chage -E 0或者usermod -L锁账号把进程踢掉等他确认没有需要交接的东西了再考虑userdel -r删用户和家目录。直接删用户容易把遗留在系统里的文件变成孤儿文件属主显示成UID数字后面清理很麻烦。4.4 删除用户前必须自查的三件事userdel -r username会删除用户并删除家目录和邮件池。但执行前一定确认三件事该用户有没有正在跑的进程pgrep -u username查一下别把人家的定时任务或者web服务给杀了。该用户有没有系统里其他重要文件find / -user username排查一下有时候用户在自己的临时目录里放了数据库备份人走了东西还在。该用户是否属于某个共享资源的管理员删掉会影响共享目录的属主显示和权限判断。生产环境里删用户要像删表一样谨慎。宁可先锁账号观察一周确认没有告警和反馈再执行真正的删除。5. sudo授权给用户“合理范围”的root能力5.1 为什么不能直接给所有人root密码这是一个反复出现的讨论既然有人需要装软件、改配置为什么不直接告诉他root密码我见过一些创业团队确实这么干——root密码全组共用一个人改了密码其他人全进不去。这种做法的根本问题是无法审计和无法收权。出了操作事故你不知道是哪个人执行的有人离职了你得改一次root密码并通知所有人更麻烦的是如果有人把root密码写到某个脚本里且没有保护好那相当于把服务器钥匙丢在了马路上。sudo机制就是用来解决这些问题的按需给特定用户特定命令的执行权所有sudo操作都会记入日志权限还能随时收回比共享root密码安全一个量级。5.2 sudoers文件的最小实用配置sudo的权限配置在/etc/sudoers里强烈建议用visudo命令编辑——它会检查语法语法错了会提示你而不会让你存盘退出。一旦sudoers格式损坏且没有被发现sudo就完全不可用届时只能用root单用户模式修复很麻烦。visudo的语法保护能规避绝大多数这种事故。先看最简单的配置逻辑。格式可以简化为三块谁、在哪台机器、能执行什么命令。zhangsan ALL(ALL) /usr/bin/systemctl, /usr/bin/dnf这个配置允许zhangsan在任何主机上以任何用户身份执行systemctl和dnf命令。注意这里最好不要随便加ALL越精确越安全。如果只是让用户重启某个nginx服务zhangsan ALL(root) NOPASSWD: /usr/bin/systemctl restart nginxNOPASSWD表示执行该命令时不需要再输密码这对脚本化操作很有用但一般不建议给太多NOPASSWD权限——每次sudo输密码本质上是一次“你确定要执行吗”的确认。如果你想让某个用户组整体具有sudo权限配置就是%develop ALL(ALL) ALL前面的%号表示后面是个组名。明文给ALL ALL是最高的sudo授权等同于给root只对完全信得过的人使用。生产环境里最安全的最小化做法是先给一组精确的命令观察用户的实际需求再逐步放权。没人会嫌权限少但权限给多了早晚会出事。5.3 sudo日志审计的隐藏价值sudo日志默认在/var/log/secureCentOS或/var/log/auth.logUbuntu里。每次执行sudo都会记录谁、在哪、执行了什么命令、几点几分。我排查过几次服务器异常都是靠翻sudo历史找出问题命令的。这个能力是共享root密码完全没有的。如果你在多台服务器统一管理sudoers建议用配置管理工具下发不要让运维人员每台机器手工登录visudo改。手工改的sudoers时间长了会产生漂移——两台机器配置不一样出了问题都排查不出来。6. 常见问题排查与避坑速查表6.1 为什么用户突然sudo不了这个排查看似复杂实际上就几条线用户不在sudo组里。Ubuntu用户默认必须在sudo组内才有sudo权限CentOS对应wheel组。groups 用户名看组成员。sudoers文件语法错。这时候任何用户sudo都会报错看/var/log/messages或直接root检查/etc/sudoers。用户被设置成nologin或用usermod -s改了shellsudo过程也可能异常。时间同步出问题Kerberos如果用了认证失败。我遇到过最隐蔽的一种运维同事把用户同时放进了多个互斥的组策略里sudoers规则冲突导致某些命令被拒绝。排查方式就是一条条grep sudoers里的规则理清优先级。6.2 为什么新用户登录后没有命令行提示符刚创建的用户登录后显示$而不是常见的[userhost ~]$或者光标前什么都没有。多半是家目录里的.bashrc没有被加载。原因通常是创建用户时没有指定shell——useradd默认可能给了/bin/sh或者根本没有创建.bash_profile。修复方案usermod -s /bin/bash 用户名然后把/etc/skel里的.bashrc复制到用户家目录如果缺失的话。实在不行就用userdel -r删掉重建这也是为什么我强烈建议创建用户时把-s参数写明白。6.3 用户无法删除自己目录下的文件这个坑特别多。很多人以为“我是这个目录的属主目录里的文件我想删就删”。真实规则是能不能删除某个文件看的是文件所在目录的写权限而不是文件本身。如果你在一个归属别人、权限为r-x的目录里哪怕你是里面某个文件的属主也删不了它。遇到这种问题先ls -ld看目录权限。如果目录被设置了粘滞位sticky bit目录权限最后一位是t情况更特殊只有文件属主、目录属主或root能删除目录内的文件。/tmp目录就是典型例子——任何人都有写权限但你不能删别人的临时文件。粘滞位的设计初衷就是这个。在共享项目目录上设粘滞位是个很实用的经验chmod t /data/project这样所有协作者都能自由上传、修改自己的文件但谁也不能误删别人的文件。6.4 误改UID/GID后文件权限错乱怎么救如果你不小心用usermod -u改了用户UID但用户原来的文件还显示成旧UID数字就说明文件没有跟着“迁移”。解决办法是用find把旧UID的文件批量改属主find /home/zhangsan -user 1005 -exec chown zhangsan: {} \;注意统一使用文件名/用户名而不是裸UID避免又搞混。这种事故也说明id映射一旦变动文件归属就会断裂所以生产环境改UID之前先全盘盘一下该用户有哪些文件。6.5 常用排查命令速查想查什么命令说明用户全部信息id 用户名UID、GID、附加组一目了然用户组列表groups 用户名主组附加组用户是否存在getent passwd 用户名兼容NIS/LDAP等远端用户源所有用户列表awk -F: {print $1} /etc/passwd简单粗暴谁在登录系统who/w当前在线用户用户最近登录last 用户名登录历史查文件属主ls -l/stat 文件看UID/GIDsudo授权清单sudo -l -U 用户名查看某用户能执行哪些命令系统里所有组getent group不比grep /etc/group弱7. 一个测试环境下的用户组管理小实践为了把上面的零散知识点串起来我设计了一个小场景你可以自己在虚拟机里复现一遍会比只看命令记忆深刻得多现状有一台测试服务器上面跑着nginx和MySQL有三个同事要上去协作A负责后端代码B负责前端资源和部署C只负责看日志排查。要求是每个人有自己的账号能登录能用sudo重启nginx。前端的静态资源目录/data/wwwA和B能读写C只能读。谁都不能用root直接登录系统。操作步骤可以这样走第一步建组。建一个web组groupadd web第二步建用户并加入相关附加组。useradd -m -s /bin/bash -c Developer A -G web deva useradd -m -s /bin/bash -c Developer B -G web devb useradd -m -s /bin/bash -c Ops C -G web devc三个人的主组各不相同各自私有组附加组都是web。第三步设置目录权限。/data/www属于web组chown root:web /data/www chmod 2775 /data/www这里用的27752是setgid位——该目录下新建的文件自动继承web组防止有人建的目录属组变成自己的私有组导致别人进不去。775赋予属主和web组rwx其他人只能读和执行。这样A、B、C都能进入但A和B要写C没有w权限所以写不了。完美满足“C只看日志不能动”的需求。第四步配置sudo。用visudo加一行%web ALL(root) NOPASSWD: /usr/bin/systemctl restart nginx只允许web组里的用户重启nginx且不需要密码。对于C这种只看日志的人这权限也够用了——他不需要systemctl stop或者改配置。第五步禁止root远程登录。修改/etc/ssh/sshd_configPermitRootLogin no然后重启sshd。以后所有人必须用普通账号登录再sudo行为全部留痕。这个案例不复杂但把用户、组、权限位、setgid、sudo、SSH安全加固全串起来了。你在自己环境里跑一遍遇到任何报错都按上面章节里的排查思路去看基本就是一次完整的学习闭环。8. 我踩过的一些坑和实际体会最后聊聊几个真实的教训。第一个是不要在用户创建时省略参数。我早期图省事useradd zhangsan然后直接让他登录结果他登录进来没有家目录shell还是sh连tab补全都没有。到后面连他自己都烦了还是得回退重建。一次图省事后面全是债。第二个是GID冲突后患无穷。有一次我用groupadd建组当时没注意GID已经被某个系统进程占用了后面把该组添加为某目录属组时目录权限莫名其妙地跟一个系统服务共享了。后来查出来是GID冲突最后只能把所有相关目录重新chown一遍。所以批量建组的时候我会刻意groupadd -g指定一个自定义范围的GID段比如10000以上避免和系统自动分配的GID撞车。第三个是批量脚本一定要有幂等性。后来我写批量创建用户的脚本在循环体里先检查用户是否已存在if id $user /dev/null; then echo $user already exists continue fi这个判断帮我挡住了很多次重复执行导致的问题。凡是自动化操作默认都要考虑“如果已经存在怎么办”不要指望现实环境跟第一次跑的时候一模一样。第四个也是很多初学容易忽略的改了sudoers必须主动开一个新终端验证。不要改完就关掉当前终端否则万一语法有问题、sudo全挂了你还得想办法恢复。我的习惯是备份一份sudoers改完先visudo -c检查语法然后另开一个终端测试sudo是否正常确认没问题才退出当前编辑会话。用户与组管理的知识树大概就到这。这些东西不算高深但覆盖面广而且每个细节都可能在生产环境里变成事故点。真正提升水平的路径就是多在实际的服务器上折腾越早把自己的账号体系、权限模型梳理清楚后面不管是部署应用还是排查安全问题都会顺手很多。