干了几年前端又转过来做运维回头一看Linux用户组和权限管理才是生产环境里最容易翻车的坑。你以为你懂chmod 777但真正线上出问题的时候八成都是用户、组、权限这三件事没咬合好某个服务起不来、某个脚本没权限执行、某台机器被同事误删了目录最后查来查去都绕回这一块。所以这篇东西我不打算从 man 手册抄一遍而是用我自己的运维视角把用户、组、权限从概念到底层到实战案例完整过一遍把我处理过的几个实际故障也一并甩出来。看完之后你至少能少踩几个月的坑。适合刚上手 Linux 的运维新人、被权限问题折磨的开发以及准备面试想补基础的兄弟。先说一个核心认知Linux 的权限管理从来不是单点问题。你改一个文件的属主、加一个用户进组、调一个目录的权限位表面上都是独立命令实际上它们共享同一套 UID/GID 模型。理解了这个模型后面所有命令都只是换着姿势在怼同一个接口。1. 先把模型捋清楚用户、组、权限到底怎么咬合的1.1 那串 rwxr-xr-x 是个三层的三元组很多人第一次接触权限是在ls -l输出里看到-rwxr-xr-x这类字符串。这串字符不是给人看的装饰它是一个九位权限矩阵按三位一组拆开正好对应三种身份属主owner、所属组group、其他用户others。每组三位分别是 r读、w写、x执行对应数字 4、2、1。没有权限就是-用 0 表示。如果你把这串东西当成文件主人说了算其他人都围观看那就太小看它了。实际作用顺序是内核拿到一个进程的请求先看它的 UID 是否等于文件属主的 UID相等就用属主那三位权限不相等再看它的 GID 是否匹配文件所属组的 GID匹配就按组权限走还不行才落到 other 的权限上。注意这里有个关键点这三个判断是互斥的而且从上往下只取第一个命中的结果。也就是说一个用户即使同时属于文件所属组只要他的 UID 正好是文件属主那走的就是属主权限不是组权限。这个细节很多人搞混后面排查权限问题时容易走弯路。1.2 UID/GID 才是内核认的东西用户名和组名是给人看的内核只认数字 ID。用户 ID 叫 UID组 ID 叫 GID。在系统里每个用户必须隶属至少一个组这个组叫初始组也叫主组它和用户是一起创建的通常名字和用户名一样。用户还可以加入很多附加组附加组的权限判定和主组是等价的只看 GID 是否匹配。查看当前用户的信息用id命令id weiqing # uid1000(weiqing) gid1000(weiqing) groups1000(weiqing),4(adm),27(sudo)uid1000说明 UID 是 1000gid1000是主组后面groups里列出的是包括主组在内的所有组。注意主组出现在第一位置附加组只是追加进去的。我见过不少同事排查问题直接用ls -l看到属主显示的是数字而不是名字就以为服务器有问题。其实不一定是系统异常很可能是 NFS 或者容器环境里 UID 没有对应的用户名解析内核只负责比对数字名字解析失败就显示数字。遇到这种情况别急着改权限先确认是不是名字解析或 ID 映射的问题。1.3 组存在的意义是分摊管理成本在没有组概念的世界里如果你想让 A、B、C 三个账号都能访问某个目录你就得把目录权限分别赋给三个用户改成任意一个用户进来又得加一条。有了组之后你只需要创建devops组把三个人都塞进去然后把目录属组改成devops组权限放开完事。这个间接层的思路是组最核心的价值。管理成本从用户数量降到组数量而组在实际业务里一般就几十个比用户数量少得多。所以你在设计权限方案时永远先想清楚角色边界再开用户、建组、挂权限。不要上来就创建用户然后直接chown给个人这种方案临时能用等人员一变动权限就全是残渣。2. 用户和组的增删改查命令少坑不少2.1 创建用户useradd 背后做了很多隐形操作新建用户最典型的命令是useradd -m -U -s /bin/bash -G devops zhangsan拆开看-m同时创建 home 目录默认路径是/home/zhangsan不写这个参数很多发行版不会自动建 home结果用户登录后连工作目录都没有。-U同时创建一个和用户名同名的组作为主组这是现代发行版的默认行为。-s指定登录 shell默认可能是/bin/sh如果你想用户能进控制台操作建议明确写/bin/bash。-G指定附加组这里把 zhangsan 加进 devops 组。创建完之后系统到底做了哪些事我列一下核心变更文件作用创建后出现什么/etc/passwd存用户基本信息一行记录包含用户名、UID、主GID、home、shell/etc/shadow存加密密码和密码策略新用户默认!!表示没设密码/etc/group存组信息若主组不存在则新建附加组也在这里记录/home/zhangsan用户家目录-m参数创建并拷贝/etc/skel下的文件很多人创建完用户直接logout然后用新账号登录发现密码不对其实用户还没设密码。你需要执行passwd zhangsan这里有个容易忽略的点passwd命令会提示你输入两次密码输入的字符不会回显很多人以为键盘坏了其实是正常行为。2.2 把用户塞进组usermod -aG 和 gpasswd 的边界给已有用户加附加组最常用的是usermod -aG devops zhangsan重点来了-a参数是append的意思表示追加。如果不带-a直接写usermod -G devops zhangsan这条命令会把 zhangsan 的附加组列表整个替换成devops也就是说原本他所在的docker、sudo组全被清空。这个坑我见过不止三次都是运维脚本手滑一个在生产机的管理员账号被降级差点酿成事故。如果你只想把某个用户加进一个组、不想动他的其他组就老老实实带-a。如果你要把用户从组里踢出去可以用gpasswd -dgpasswd -d zhangsan devopsgpasswd还有一个用途是设置组密码和管理组成员不过在生产环境里我很少用组密码组权限要么给要么不给搞密码反而增加管理复杂度。还有个冷门但实用的知识点一个用户同时属于多个组时他创建文件时默认所属组是主组。如果你希望他在某个共享目录里创建的 new 文件都自动归到共享组就需要用到后面会讲的setgid目录位。2.3 批量导入和清理运维效率全靠跑脚本服务器初始化时最容易遇到批量建用户的需求。一条条useradd敲到什么时候我一般先把用户信息写进文件再循环处理while IFS: read -r user group shell; do useradd -m -U -s $shell $user usermod -aG $group $user done /tmp/users.txt/tmp/users.txt的格式很简单一行一个用户冒号分隔zhangsan:devops:/bin/bash lisi:dev:/bin/bash wangwu:ops:/bin/sh这样批量创建并不难难的是后续权限分配。如果你创建的用户要同时访问某个共享目录就需要在脚本里把共享目录的属组和权限一起改好。我通常会把用户创建、组创建、目录初始化放在同一个初始化 playbook 里保证同一批用户拥有一致的入口权限。删除用户时注意userdel默认不会删 home 目录和邮件目录。要彻底清理就加-ruserdel -r zhangsan但这个操作要谨慎-r会把用户的主目录整个删掉如果里面放的是脚本没确认过的重要数据那就真的找不回来了。删用户前先归档 home 目录是最稳的做法。3. 改权限的正确姿势3.1 chmod 数字到底怎么算权限数字是转成二进制再叠加的。r 对应 2 的 2 次方即 4w 对应 2 的 1 次方即 2x 对应 2 的 0 次方即 1。所以rwx 4 2 1 7rw- 4 2 0 6r-x 4 0 1 5r-- 4 0 0 4三组一组就拼出了 755、750、640 这类常见组合。644是普通文件的经典权限属主可读写组和其他人只读。755是脚本、二进制程序的常见权限属主可读写执行组和其他可读执行。750适合目录属主和属组有全部操作权其他用户完全无法进入。700适合私密目录除属主外谁都进不去。直接给目录整体改权限最常用chmod -R 750 /data/project-R参数是递归对目录下所有文件和子目录生效。这里有个大坑-R会把目录里的所有普通文件也设置成 750而普通文件通常不需要执行权限这么一搞很多文件就有了 x 位合规检查扫出来就是一大片风险项。更细的做法是用两条命令分开处理find /data/project -type d -exec chmod 750 {} \; find /data/project -type f -exec chmod 640 {} \;先给目录设 750再给文件设 640这样既保证目录可进入又避免文件被无端加上执行位。文本文件带 x 位虽然不会立刻出问题但安全扫描工具会报异常没必要留这种隐患。3.2 chown 和 chgrp别只记得改属主改属主用chown改属组用chgrp但chown也可以同时把属组改了chown zhangsan:devops /data/project这个写法把属主改为 zhangsan属组改为 devops。在共享协作场景里属主一般写某个管理员或服务账号属组写业务组权限位再控制组里的成员能做什么。实际操作时chown -R也是常用操作chown -R root:ops /var/www/html递归改属主前要想清楚目录下可能有特殊文件比如 socket 文件、设备文件递归改属主可能导致服务异常。另外还要注意如果目录里存在硬链接chown -R不会跟着改硬链接指向的 inode 内容只会改你遍历到的那个路径这个细节在非普通文件系统上尤其磨人。3.3 SUID、SGID、Sticky Bit 三个特殊位这是面试官最爱问、生产环境最容易被塞进来的三个位。SUID4用在可执行文件上时该进程的有效 UID 会变成文件属主的 UID。最典型的是/usr/bin/passwd你执行它时内核会以 root 身份运行即使你自己不是 root也能改密码文件。SGID2用在可执行文件上类似 SUID但作用于 GID用在目录上时目录中新创建的文件会自动继承目录的属组这是共享目录最核心的机制。Sticky Bit1用在目录上时目录里的文件只能被文件属主、目录属主或 root 删除其他用户即使是这个目录的写权限也删不了别人的文件。典型的是/tmp。设置这几个位的方式是chmod us /some/file # SUID chmod gs /some/dir # SGID chmod t /some/dir # Sticky数字写法也讲一下特殊位占用权限位最高位的三个 bit所以chmod 1777 /tmp表示 rwx 全开加 stickychmod 2755 /shared表示 sgid 加 755chmod 4755表示 suid 加 755。线上我见过最闹心的就是有人给脚本文件设了 SUID脚本的内容还是写死的能够改系统配置的命令这等于给了所有可执行用户一个定时炸弹。排查 SUID 文件可以用find / -perm /4000 -type f -exec ls -l {} \;定期审计一遍发现不该带 SUID 的文件直接chmod u-s去掉。3.4 默认 umask 也会坑人新建文件或目录的时候权限不是从 0 算起而是从最大权限里减去 umask 中的位。umask 通常用四位八进制表示比如0022但实际生效的是后三位022。对普通文件最大权限是 666对目录最大权限是 777。所以 umask 为 022 时新文件666 - 022 644新目录777 - 022 755如果 umask 是 027新文件就是 640新目录就是 750。这就是为什么同一台机器上不同用户创建的文件权限不一样不是命令的问题是各自的环境里 umask 设置不同。查看当前 umask 用umask临时修改用umask 027要持久化就得写到/etc/profile或用户的~/.bashrc。如果你想让共享目录里新生成的文件默认对组可读写就得把 umask 改成 007但这样其他用户也会失去访问权具体得看业务场景。4. 实战案例添加 network service 用户组并放开完全控制权限4.1 需求描述与常规操作这个案例是我处理过的一个真实需求某个中间件服务要用network这个系统账号运行同时需要让network:service这个组的成员能够对/opt/mw-data目录拥有完全控制权限包括读、写、执行、创建子目录、删除文件。这个需求表面上是添加组 放开权限实际要做的事比听上去多确认network用户是否已存在没存在就创建。新建service组并把network用户加进组。把/opt/mw-data的属组改成service。设置组权限为完全控制即 rwx。由于是新加的组还要考虑目录里已有的旧文件是否也要同步放开。一步一步来id network || useradd -r -s /usr/sbin/nologin network groupadd service usermod -aG service network chown -R :service /opt/mw-data chmod -R grwx /opt/mw-data到这一步目录里的文件已经全部归service组组权限是 rwx组内成员可以自由操作。4.2 为什么会报方法失败,意外上面这套命令看起来没什么问题但我在实际执行时遇到过一个诡异报错。用某个带图形界面的管理工具去执行gpasswd -a network service时界面上直接弹出一句“方法失败意外”英文环境下是Method call failed: Unexpected。第一次碰这个错我以为是gpasswd执行权限不够或者 DBus 服务异常。但后来排查发现问题出在管理工具所依赖的 DBus 会话权限上它尝试通过 systemd-logind 获取用户会话信息时失败了而gpasswd本身在终端里跑得好好的。这类问题的排查思路是先看报错是在哪个层图形工具报 DBus 错误就检查 DBus 相关服务命令行工具报权限错误再查 PAM 和权限位。不要一上来就以为系统权限配置坏了。如果确实需要在命令行里跨 DBus 会话操作可以试试重启相关服务systemctl restart dbus systemctl restart systemd-logind但这两个服务在生产环境重启有风险会影响当前登录会话建议在维护窗口操作。4.3 最终能落地的一组稳定命令闭着眼睛可以用这个组合拳解决同类需求groupadd -f service usermod -a -G service network chgrp -R service /opt/mw-data chmod -R grwx /opt/mw-data注意groupadd -f的-f参数如果组已经存在命令不会报错直接跳过适合幂等脚本。另外如果你希望以后在/opt/mw-data下新建的文件也自动属于service组那就给目录设 SGIDchmod gs /opt/mw-data这样无论哪个用户在这个目录下创建文件文件的属组都会自动变成service而不是该用户的主组。这个技巧在共享目录场景里非常实用。5. 故障排查权限问题的定位套路5.1 Permission denied 的排查顺序遇到Permission denied别急着chmod 777按顺序排查ls -ld /path/to/dir ls -l /path/to/file id username第一步看目录的权限位第二步看文件权限位第三步看用户的组关系。很多时候不是文件权限没给够而是用户压根不在对应的组里。举个例子你让 nginx 用户读一个/var/log/app目录下的日志目录权限是drwxr-x---属组是applog而 nginx 用户不在applog组里那不管文件权限怎么放宽nginx 都进不了目录。因为目录的 x 权限是进入目录的前提没有 x文件读写权限再大也没用。还有一个非常隐蔽的路径问题访问文件时路径上每一层目录都要有足够的 x 权限。比如/home/zhangsan/project/file.txt/home、/home/zhangsan、/home/zhangsan/project都必须对当前用户开放 x 权限。/home/zhangsan如果是 700 且属于 zhangsan 本人那你即使对 project 目录设置了 755也无法进入因为中间那层挡住了。5.2 排查路径是不是忘了组权限如果说前面是没权限的常规排查那有权限但不生效往往出在组的关系上。我遇到过一次用户 userA 和 userB 都属于project组目录/data/project属组是project权限是 770。userA 创建文件后userB 竟然无法编辑这个文件。一查发现 userA 创建文件时文件属主是 userA属组却是 userA 的主组userA而不是project。原因就是目录没有设置 SGID所以新建文件不会自动继承目录的属组。解决办法就是给目录chmod gs /data/project同时把已有文件统一递归改属组chgrp -R project /data/project chmod -R grwx /data/project chmod gs /data/project5.3 排查特殊位和ACL带来的干扰传统权限满足不了需求时有人会偷偷加 ACL访问控制列表。一旦加了 ACLls -l显示的传统权限位就不再是完整信息权限判断可能被 ACL 覆盖或扩展。当你发现明明权限写对了还是报错时用getfacl看一下getfacl /data/project如果输出里有很多user:、group:开头的条目说明 ACL 在起作用。ACL 的优先级比传统权限高具体来说匹配顺序是进程用户是否匹配文件属主 是否匹配 ACL 中的用户条目 是否匹配文件属组 是否匹配 ACL 中的组条目 其他用户。这个顺序已经是内核实现好的没有骚操作可以绕过。遇到 ACL 导致的诡异问题最简单的清空方法是setfacl -b /data/project-b把全部 ACL 条目删掉回到传统权限模型。但注意这会把别人精心配置的细粒度权限全部抹掉操作前记得先备份 ACLgetfacl -R /data/project /tmp/project_acl_backup.txt后面有需要再用setfacl --restore恢复。6. 进阶ACL 和 sudo6.1 ACL 解决的是你没这个组怎么办传统权限只有三位属主、组、其他一旦项目需要某个人单独可写其他人只读传统权限位就尴尬了。你不能把这个人加到组里因为组里还有其他人加了就变成组内所有成员都可操作权限范围扩大。ACL 可以精确到单个用户setfacl -m u:zhangsan:rwx /data/project这样 zhangsan 对这个目录有 rwx而组和其他人的传统权限不变。这个能力很实用比如让审计人员单独读某些目录又不想让他改。ACL 也支持递归setfacl -R -m u:zhangsan:rwx /data/project新文件继承 ACL 需要为目录设置默认 ACLsetfacl -d -m u:zhangsan:rwx /data/project不过 ACL 在跨文件系统复制时容易丢失比如cp -a通常能保留但rsync -a里如果没加-A参数ACL 就不会同步过去。跨服务器迁移共享目录时这个坑很常见。6.2 sudo 的配置原理与提权安全用户组和权限管理里sudo 也是绕不开的。/etc/sudoers的标准写法是按组授权%devops ALL(ALL) ALL%开头表示组名整条意思是devops组的所有成员可以在任何主机上以任何用户身份执行任何命令。更精细的授权是只放行必要的命令%ops ALL(root) /bin/systemctl restart nginx这样运维组成员只能重启 nginx不能执行其他 root 命令。这种最小化授权特别适合生产环境。改 sudoers 前必须用visudo而不是直接编辑文件因为visudo会做语法校验防止你把语法写错导致所有用户都无法 sudo。即使这样我还是养成了先把 sudoers 备份再改的习惯cp /etc/sudoers /etc/sudoers.bak.$(date %F) visudosudo 在设计上没有全有全无的说法。很多面试题会问能否让某个用户只执行某条命令而不给完整 root 权限答案是完全可以而且这是生产实践里最常用的做法。但要注意给命令级别的 sudo 权限时要考虑命令本身能不能被滥用。比如你只放开vim /etc/passwd那用户完全可以借 Vim 的 shell 功能直接执行任意命令等于给了一个完整的 root shell。这类看似封死其实漏风的授权方式是提权安全的核心关注点。6.3 面试里最高频的权限题怎么答结合我面试候选人和被面试的经历列举几个极高频的 looting 题chmod 777和chmod 1777有什么区别一个是普通权限一个是加了 sticky bit。一个用户在一个目录里能创建文件为什么删不了别人的文件因为目录没有写权限或者有写权限但没有 sticky bit 保护或者对方文件属于其他组而你不在那个组里。SUID 和 SGID 有什么区别SUID 影响进程的有效 UIDSGID 用在文件和目录上的语义不同文件层面影响有效 GID目录层面控制新文件自动继承属组。umask 027创建文件和目录的默认权限是多少文件 640目录 750。如何递归修改某组目录下所有文件的属组chgrp -R group dir或者chown -R :group dir。回答这些问题别光背定义能结合具体场景说明就更有说服力。面试官想听的不是我知道 SUID 叫 Set User ID而是我知道什么场景该用、什么场景绝对不能碰。7. 日常维护里的几个实战心得最后说点我个人的操作习惯算不上标准答案但踩坑踩多了自然形成的。第一能用组解决的问题不要逐个用户设权限。用户会流动组是相对稳定的角色边界。我见过一个小公司把所有操作都通过chown给到个人账号结果核心员工离职那天一堆服务起不来因为权限挂在个人账号上账号一删什么权限都没了。第二修改权限之前旧状态一定要留档。我习惯把关键目录的权限快照存下来ls -ld /data/project getfacl -R /data/project /backup/project.acl万一改出问题还能立刻回滚。很多时候生产事故不是不知道正确命令而是改之前没留备份。第三给脚本和服务账号尽量用 nologin shell。如果账号只是跑服务、不需要交互登录创建时加-s /usr/sbin/nologin能减少被暴力爆破后的直接 shell 风险。服务账号的密码尽量不设用密钥或 token 认证更安全。Linux 用户组和权限管理说到底就是一套规则清晰的资源访问控制体系把 UID/GID 模型、组关系、权限位、ACL、sudo 这几层想清楚绝大多数权限问题都能在几分钟内定位。我自己刚入门时也被那串 rwx 搞得一头雾水真正摸透还是从两次线上事故开始的。希望这篇基于实际运维视角的梳理能帮你少走那段弯路。
