先聊个很多人都踩过的场景。你高高兴兴把一个开发同学加进了某个用户组跟他说“权限都给你开了”结果他那边一执行还是Permission denied。你再一看用户组没加错、文件属主也对、rwx 权限位看着也没毛病就是访问不了。这种诡异问题我碰到过不下十次最后八成都是目录中间层的x权限丢了或者被 ACL、SELinux 这种“隐藏关卡”拦了一道。Linux 账号和权限管理这门课说难不难说简单也真不简单。它既是面试里最高频的基础题也是日常运维和开发环境里最容易出幺蛾子的环节。这篇我不打算写成一章教科书式的命令大全而是把所有跟账号、用户组、文件权限相关的核心逻辑从/etc/passwd到 SUID/SGID 再到 ACL全部串起来讲清楚再带一套可以直接照着抄的实操脚本。无论你是刚入门的新手还是被诡异权限问题折磨过的老开发这篇应该都能让你少走点弯路。1. 账号管理用户和组的底层逻辑1.1 三个关键文件读懂整个账号体系Linux 里没有“用户数据库服务”所有账号信息都落在几个文本文件上最核心的三个就是/etc/passwd、/etc/shadow和/etc/group。很多教程会把重点放在命令上但我强烈建议先从这三个文件下手——命令只是壳文件里的字段才是魂。先看/etc/passwd每一行对应一个账号典型的行是这样的root:x:0:0:root:/root:/bin/bash devops:x:1001:1001::/home/devops:/bin/bash每行用冒号分成 7 个字段第一个是用户名第二个x不是密码本身而是表示密码哈希被影藏到了/etc/shadow里。后面是 UID、GID、用户描述信息、家目录、登录 Shell。这里有个知识点特别容易引起误会不是所有用户都能“登录”比如nobody:x:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin这种。把登录 Shell 指到/sbin/nologin或者/usr/sbin/nologin这个账号就不能被用来 SSH 登录但照样可以跑服务、作为进程身份存在。这是做最小权限设计时一个非常实用的手法。密码真正的存放点是/etc/shadow它每行的格式是devops:$6$随机盐值$哈希值:18800:0:99999:7:::第一个字段是用户名第二个是最关键的密码哈希。$6$开头表示 SHA-512 算法$5$是 SHA-256$1$是老旧的 MD5。后面依次是密码最后修改时间从 1970 年 1 月 1 日算起的天数、两次修改最小间隔天数、密码有效期、到期前警告天数等。这几个字段对应chage命令的调整项后面实操部分我会展开讲。/etc/group则是组的定义文件格式是devs:x:1002:zhangsan,lisi,wangwu从左到右是组名、组密码占位、GID、附加组中的成员列表。主组成员不在这个列表里显示而是靠/etc/passwd里的 GID 字段来确认。我举一个实际教训。刚学 Linux 的时候我在一台测试机上直接vim /etc/passwd手工加账号以为格式照葫芦画瓢就行结果保存之后发现su切不过去最后才发现是 shell 字段拼错了一个字符。从此之后我就养成了一个习惯非极端情况绝不手工编辑这三个文件而是用useradd、usermod、groupadd这些标准命令。它们背后做的事情本质上也是改文件但会做参数校验出错了也好定位。如果非改不可改完记得跑一遍pwck和grpck校验。1.2 UID、GID 和用户组关系的设计要点UID 不是随便分配的。传统约定是0给root1-999是系统账号不同发行版划分有差异CentOS 和 Ubuntu 在这个区间上不太一样普通用户的 UID 从1000开始。为什么这么分因为很多服务进程需要以特定身份运行但又不能让它们拿到管理员权限系统账号就是干这个的。比如 nginx 的 worker 进程常用nginx这个系统账号来跑即使被攻击者利用也不会直接获得 root 级权限。用户组的关系里有个高频考点主组和附加组。每个用户有且只能有一个主组primary group同时可以加入多个附加组secondary group。用户创建文件时文件的属组默认继承用户的主组跟你当前在哪个目里没关系。如果你希望某个用户新建的文件“天然”属于某个项目组要么把他的主组改掉要么借助后面要讲的 SGID 特殊权限。举个实际案例。我们公司有个项目目录/data/webapp前端组和后端组都要访问但两者权限不一样。如果大家的主组规划得乱七八糟权限控制就完全没法做。正确的做法是先建两个组frontend和backend再给每个人加对应的附加组目录通过组权限来控制——这比把某一个人单独设成目录属主再挨个授权要清晰得多。记住一条经验组设计要在建号之前就想好不要等用户建了一堆再去捣鼓。组是权限管理的最小“集合单位”组规划得好后面的chmod、chown全都能省下大量重复劳动。2. 文件权限体系拆解2.1 权限位的读法rwx 到底是谁的 rwx用ls -l看任意一个文件第一列十个字符大概是这个样子-rwxr-xr-- 1 devops devs 1024 Jan 15 10:00 app.py第一个字符是类型d是目录、-是普通文件、l是软链接、c是字符设备、b是块设备。剩下九个字符分三组每组三个属主权限、属组权限、其他用户权限。这里不展开每个字符但目录和文件的 rwx 含义是不一样的很多人在这里理解出了偏差。对普通文件来说r是能读内容w是能修改内容x是能当程序执行。对目录来说r是能列出目录里的文件名w是能在目录里新增、删除、重命名文件x是能“穿过”这个目录访问里面的具体文件。也就是说你要进入一个目录并读取里面某个文件必须同时拥有文件的r和目录的x缺一不可。这就能解释很多线上故障。比如排查问题时发现文件权限明明是644属主可读写其他人只读但普通用户进去就是Permission denied。往上一查原来中间某个父目录权限是700其他用户根本没有x权限整个路径被“拦腰截断”了。我后来排查这类问题直接三步走先namei -om /完整/路径看整条路径的权限再检查文件自身 ACL最后看 SELinux效率高很多。2.2 chmod、chown 和 umask 的正确用法chmod有两种设置方式。符号法直观适合人看chmod ux file给属主加执行权限chmod g-w,o-rwx file把属组的写、其他的读和写一起去掉。数字法是脚本里最常用的因为格式紧凑且可预测r4、w2、x1一组权限算一个数rwxr-xr--就等于750。数字法有个小坑它默认把没有写出来的特殊权限位全部清零。比如一个文件原本是4755带 SUID你执行chmod 755 fileSUID 就没了。这不算 bug但很多人在修改权限时没留意这一点导致原有特殊权限被静默清除。稳妥的做法是先ls -l看一眼再动手。chown用来改属主和属组最常见的格式是chown 用户名:组名 file注意中间是冒号不是点。还有个有用的参数-R递归修改目录下所有内容但使用时要相当克制——线上环境一个大范围递归chown可能导致服务起不来这个我后面在“常见问题”里会详细说。umask是另一个容易被忽略的点。它决定了新文件默认权限的“减去值”。Shell 里执行umask会看到一个三位数字比如022这个数字的每一位分别对应属主、属组、其他用户的被屏蔽权限。新文件的默认权限计算公式文件是666减 umask目录是777减 umask。所以 umask 是022时新目录是755新文件是644。如果你希望团队协作时新文件自动让组内可写把 umask 设成002比较合理——这算是一个提升协作效率的小技巧但也带来安全性代价需要自己权衡。2.3 特殊权限SUID、SGID、Sticky Bit普通的 rwx 权限之外Linux 还有三个特殊权限位。它们经常出现在面试题里也经常在线上环境制造麻烦。SUIDSet User ID作用于可执行文件。文件带 SUID 时执行它的进程会临时获得文件属主的身份而不是执行者自己的身份。最经典的案例是passwd命令普通用户修改自己的密码要写/etc/shadow但这个文件只有 root 能写没有 SUID 的话改密码这个操作根本没法做。ls -l /usr/bin/passwd你会看到-rwsr-xr-x那个s就是 SUID 标志。SUID 是一把双刃剑一个不小心就把自己给背刺了。如果某个 root 所有的脚本或程序带了 SUID而且里面存在漏洞攻击者就能借助它提升权限。更难受的是SUID 不会在解释器脚本比如.sh、.py文件上生效这是内核刻意为之的安全决策。我的经验是不到万不得已不上 SUID能用 sudo 解决就优先用 sudo。SGIDSet Group ID有两个作用。作用于文件时效果类似 SUID但身份换成了文件的属组。作用于目录时它能让该目录下新建的文件自动继承目录的属组而不是继承创建者的主组。这一点在项目协作中太重要了。比如/data/webapp属组是webteam给目录加上 SGID 之后不管谁来创建文件文件属组都是webteam省去了反复chown的麻烦。Sticky Bit粘滞位主要用来保护目录。最典型的就是/tmp它允许任何用户往里面写文件但不允许用户删除“不属于自己”的文件——即使目录权限写的是777。ls -ld /tmp会看到drwxrwxrwt的结尾t。这个场景可以类比成一个公共储物间谁都能往里存东西但只能取走自己存的那一份。特殊权限的设置在数字法里对应第 4 个前缀数字4是 SUID2是 SGID1是 Sticky Bit还可以组合。比如chmod 1777 /data/share就是给/data/share设置粘滞位且权限是777。符号法也能设chmod us、chmod gs、chmod ot。检查时可以看ls -l的输出但要注意如果文件原本没有执行权限特殊权限位会显示为大写S或T表示这个位虽然设了但不生效——这种“半吊子”状态经常让人看走眼我就在这里吃过亏。3. 实操从新建用户到权限落地3.1 用 useradd 创建标准用户并设置密码策略手动改文件加用户这种事我早就不干了标准做法是用useradd。假设我们要创建一个部署账号deploy把它加入ops附加组并指定登录 Shell 和家目录useradd -m -d /home/deploy -s /bin/bash -G ops deploy参数解释一下-m是如果家目录不存在就自动创建-d指定家目录路径-s指定登录 Shell-G指定附加组。如果不加-m很多发行版不会自动建家目录后面切换到该用户时会发现cd ~路径都不对。创建完用户后密码处理也有讲究。交互式执行passwd deploy最安全但脚本化部署时我们需要非交互方式echo 临时密码123! | chpasswd这条命令会从标准输入读取用户名:密码适合批量初始化。生产环境我建议紧接着做两件事强制首次登录改密码以及给密码设置生命周期。强制首次登录改密码的核心是设置chagechage -d 0 deploy-d 0表示把密码最后修改时间设为 1970-01-01这样用户最近一次登录后必须马上修改密码。给密码设有效期则是chage -M 90 -m 7 -W 14 deploy-M 90表示密码 90 天后过期-m 7表示两次修改密码的最小间隔是 7 天-W 14表示过期前 14 天提醒用户。这几个参数是很多公司账号合规审计的硬性要求提前设置好能省去后期补台账的麻烦。新手常犯的一个错误是只用useradd忘了passwd结果用户建好了密码压根没设。这时候用户既不能登录也看不出什么问题排查起来很迷惑。我的建议是每次建号后立刻用一条命令验证账号状态id deploy chage -l deployid看用户与组信息chage -l查看密码策略明细两个都正常再宣布建号成功。批量创建用户的场景下我更推荐newusers配合chpasswd。先把用户信息写成一个格式与/etc/passwd一致的文件newusers users.txt批量导入然后再用chpasswd passwords.txt统一设置密码。只要数据文件格式没问题几十个账号几秒钟就建完了效率比手工useradd高出好几个档次。3.2 项目目录权限规划一个可以直接照抄的案例接下来用一个完整案例演示权限落地的全过程。假设场景是服务器上有个项目目录/data/webapp有两个组——dev开发组可读写和ops运维组可读写也可执行一些部署脚本还有一个人zhangsan外包同事只允许读取。第一步创建组并把人加进去groupadd dev groupadd ops usermod -aG dev zhangsan usermod -aG dev,ops lisi-aG的-a特别重要它表示 append追加。如果不加-ausermod -G会把用户原有的附加组全部清掉只保留命令行里指定的组。这个操作我在生产环境误用过一次当时差点把用户的权限全部清空想想都后怕。第二步创建目录并设置属主、属组和基础权限mkdir -p /data/webapp chown root:dev /data/webapp chmod 2770 /data/webapp这里chmod 2770里的2是 SGID目的是让目录下新建的文件自动继承dev组这是整个协作机制的核心。770表示属主root和属组dev都有完整的读写执行权限其他用户无权访问。第三步给ops组和zhangsan单独授权。传统 rwx 权限无法实现“主组可写另一个组只读某个人只读”这样细粒度的区分这时就要上 ACL 了。之前写过一遍 ACL 命令这里再展开一层。先给ops组加读和进入目录的权限setfacl -m g:ops:rx /data/webapp再给zhangsan加只读setfacl -m u:zhangsan:r-x /data/webapp注意ACL 规则里的x对目录来说是必需的没有它zhangsan连目录都进不去更别提看文件了。很多新手只给r权限结果对方一ls又报错就是这个原因。要想让zhangsan之后在该目录下新建的文件依然保持只读可以设默认 ACLsetfacl -m d:u:zhangsan:r-x /data/webappd:前缀表示 default作用于目录后会影响未来在该目录下新建的文件/子目录。这是继承机制不是实时生效所以要提前设而不是等文件建了再补。最后用getfacl检查getfacl /data/webapp输出里能看到 user、group、mask、default 等条目。有一个mask字段值得单独解释它相当于所有命名用户、命名组和属组权限的“上限”。即使某条 ACL 写了r--如果 mask 是r--实际生效的就是r--。这个 mask 会在执行chmod时被自动重新计算所以如果你在设置了 ACL 的目录上跑了一次chmod g-w搞不好后脚就把人家组权限给削了。遇到“ACL 明明写了但权限没生效”的怪事首先查 mask。3.3 从删除账号到回收权限离职流程同样重要权限管理不仅管“给”也要管“收”。常见场景是员工离职或转岗账号需要禁用或删除。标准做法不是直接userdel -r deploy一刀切而是分两步。第一步先把密码锁定让账号无法立即登录usermod -L deploy或者更彻底一点把 shell 改成nologinusermod -s /sbin/nologin deploy第二步才是根据审计需求决定是保留数据还是删除账号。如果需要彻底删除账号、家目录和邮件池userdel -r deploy如果暂时不想删但希望保留家目录中的数据就把userdel -r分成两步先注释掉/etc/passwd里的账号或者锁密码把家目录打包归档过了审计期再彻底清除。这里我要补一个容易忽略的点删除用户不会自动删除这个用户在其他地方留下的文件。比如某个用户是/data下大量文件的属主userdel之后这些文件的属主会显示为一串数字 UID。所以删账号前先全局扫一遍该用户拥有的文件find / -user deploy -ls 2/dev/null尤其是 web 目录、数据目录、定时任务脚本都得检查一遍。有次我删掉一个账号后当天夜里一个 cron 脚本因为属主消失而执行失败日志里全是 “user not found”排查了很久才意识到是账号删早了。后来我养成了习惯锁账号后至少观察一周确认定时任务和进程都不依赖这个账号再执行最终删除。4. 常见问题与排查技巧4.1 文件删除不了问题可能在父目录而不是文件本身很多新手会纠结于文件自身的权限但文件能不能被删除规则取决于它所在的目录。删除一个文件本质上是修改目录里“文件名到 inode 的映射”所以看目录有没有写权限就够了。举个具体例子。用户zhangsan想删一个文件文件的权限明明是666所有人都可读写但rm依旧报Operation not permitted。这时候去看它所在目录的权限很可能目录是755其他用户没有写权限因此zhangsan根本没有删除文件的资格。另外还要检查两类特殊标志。一类是目录上的粘滞位比如/tmp和公共上传目录即使其他用户有写权限也不能删别人的文件。另一类是文件上的隐藏属性用lsattr查看lsattr 文件名如果看到iimmutable或aappend-only标志那么即使是 root 也删不掉。i表示文件不可修改、不可删除、不可重命名a表示只能追加内容。这些属性需要用chattr来设置或解除比如chattr -i 文件名。我曾经遇到一种情况安全加固脚本给某些日志文件加了a属性结果运维轮转日志时发现删除不了查了一圈才找到原因直接把锅甩给了安全策略。4.2 权限看着没问题但就是访问不了从这几层排查遇到“权限神秘失效”我推荐按下面这个顺序排查效率最高。第一层检查整条路径的目录权限。用namei -om /data/webapp/config/app.yml它会列出路径中每一层的属主、权限和 ACL一目了然。九成的问题在这一层就能定位。第二层检查 ACL 的 mask。执行getfacl /data/webapp重点关注mask是不是把权限下限抬高了。mask 被chmod意外改小的案例非常多我建议在脚本里一旦执行过chmod紧接着就getfacl复核一次。第三层看 SELinux。执行getenforce如果输出是Enforcing那可能就是 SELinux 在拦截。再执行ls -Z看文件的安全上下文跟同目录下能正常访问的文件做对比。临时放行可以用chcon或restorecon但长期建议认真排规则。这个场景真的非常普遍根目录下迁移过来的一组文件SELinux 上下文变成了默认的conf_t而不是httpd_sys_content_tnginx 死活读不了日志里又没有明显的权限报错。排查权限问题时sealert和/var/log/audit/audit.log都能给出明确线索。第四层确认 sudo 环境中的 PATH 问题。这个问题不在文件权限但挺有迷惑性。sudo执行命令时默认使用 secure_path可能跟你当前 Shell 的 PATH 不一致。这会导致你在自己终端里能敲nginx -t但sudo nginx -t却说命令找不到。遇到这种用sudo /usr/sbin/nginx -t或者编辑/etc/sudoers里的secure_path都能解决。4.3 sudo 授权用最小权限防住最大事故账号权限做完后管理员常常面临另一个需求给开发或运维人员一个“临时 root”能力但不能把 root 密码交出去。解决思路是 sudo。sudo的配置文件是/etc/sudoers强烈建议不要直接vim去改而是用visudo。它自带的语法检查能防止你把自己锁在门外——如果你写坏了 sudoersvisudo会在保存时报错并拒绝写入而vim直接写坏的后果可能是所有人包括 root 都没办法用 sudo 提权了。一个实用授权示例如下dev ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx ops ALL(ALL) /usr/bin/systemctl restart *, /bin/systemctl stop *第一行表示dev用户可以在所有主机上不需要输入密码就执行 nginx 重启命令。第二行表示ops组可以重启或停止所有 systemd 服务但要求输入自己的密码。NOPASSWD要谨慎使用——方便归方便但一旦账号被入侵攻击者连密码都不用猜就能执行授权命令。关于 sudo 授权我的建议是能细分到命令就直接写命令尽量少给ALL(ALL) ALL这种“等于送 root 外壳”的权限。线上环境真有“给个 root 权限方便一点”的想法往往就是事故的开端。配好之后让用户执行sudo -l检查自己的授权列表一眼能看到自己到底能提权做什么。这是验证 sudoers 是否生效最快的方式。5. 最后再分享几点经验账号和权限管理的核心说穿了就是“最小权限”四个字。在建号、授权、设置目录权限之前先问自己一句这个人、这个进程、这个脚本真的需要这么多权限吗不需要的权限越少越好这样即使出问题影响面也小。实际操作中我会额外坚持几个习惯。第一每建一个账号、每做一次权限变更都在变更记录里写一笔包括变更人、时间、授权依据方便后期审计。第二定期扫一遍系统中长期不登录的账号和异常的 UID 0 账号——一个安全的系统根本不应该出现多个 UID 0 的“平行 root”。第三每次执行批量chmod、chown之前先备份 ACL 和属主信息getfacl -R /data/webapp /tmp/webapp.acl.bak真出问题时恢复成本极低这条小命令帮我省掉了不少运维事故。这套账号和权限管理的体系越早想明白你后面踩的坑就越少。