权限排查这事说难其实不难说简单却有大量细节藏在细节里。这两天连续有几位读者私信问同一类问题为什么目录权限已经改成777了服务还是写不进去文件为什么有的文件用root能看到用普通用户就是没反应还有一位朋友把整个站点目录chmod -R 777结果越改越乱最后连日志都起不来了。这些问题背后其实都指向同一个根源——对Linux权限模型的理解停留在读、写、执行三个单词的表面而没有真正搞懂权限在文件、目录、进程这几层之间是怎么联动的。我决定把这些年踩过的坑和排查思路整理成一篇完整的文章从权限模型讲起一直到特殊权限位、默认权限、ACL、排障方法论争取做到无论是刚入行的新人还是干了几年还偶尔头疼的老手都能从中找到自己需要的干货。1. 先把权限模型的三层结构讲透1.1 属主、属组、其他人三种身份到底在说什么Linux里每个文件都有三组权限分别对应属主u、属组g、其他人o。用ls -l查看时第一列形如-rw-r--r--共10个字符第一个字符表示文件类型剩下的9个字符分成三组每组三位对应一种身份的r、w、x权限。这里有个很多人忽略的细节所谓其他人o指的是既不是文件属主、也不属于文件属组的那些用户。注意不属于文件属组这句话指的是用户的附加组和主组都不在这个文件的属组里而不是没有登录系统的陌生人。很多人以为others就是所有非属主用户这个理解是错的。实际上如果一个用户属于文件属组他的权限由g这一组决定而不是o。举个例子某站点目录属主是www属组也是www而某个执行排查的运维账号恰好被加入了www组那么他看到的文件权限要以第二组g为准而不是第三组o。这一点在排查为什么这个用户能访问文件的时候特别关键。1.2 读写执行的真实含义不只字面那么简单r、w、x在执行对象是文件还是目录时含义差别极大这是权限上最容易栽跟头的点。对普通文件来说r代表可以读取文件内容w代表可以修改文件内容但不代表能删除文件本身x代表可以把文件当作程序或脚本来执行。这里引出一个常见误区——我有写权限就能删文件吗答案是否定的。删除文件这个操作取决于你对文件所在目录是否有w和x权限而不是对文件本身是否有w权限。这个机制初看反直觉仔细一想很精妙文件内容与文件条目是两回事Linux把修改内容和删除文件条目刻意区分开了。对目录来说r代表可以列出目录下的文件名w代表可以在目录内创建、删除文件或子目录x代表可以进入目录也常被称为穿过目录。注意一个冷门但重要的点只有r没有x你用ls能看到文件名列表但cd进不去也无法访问目录内文件的任何元数据这会让很多命令出现半残废现象。比如ls -l能列出名字但所有文件的属性都显示问号或无权限原因就是缺少x导致的。把文件权限和目录权限混在一起想很多问题就有解了。某站点上传目录属主是www:www权限755里面新上传的文件权限是644。另一个用户非www组想要读取该文件他必须先拥有该目录的x权限才能进入目录再拥有文件本身的r权限才能读取。只要目录只允许属主进入哪怕文件是666外部用户仍然拿不到内容。很多人的安全加固其实只需要卡住目录的执行权限就够了不用把每个文件的权限都改得死死。1.3 root为什么不受权限限制root可以无视几乎所有DAC权限检查后面要讲的SELinux除外它能读任何文件、写任何文件、进入任何目录。但这里要注意root虽然可以无视权限却不代表文件上的权限位没有意义。比如某个可执行脚本没有x位root用./script.sh执行仍会报Permission denied因为内核虽然在DAC层放行了root但execve这一层仍然要求文件至少在属主位上有一位x权限这是由二进制的可执行格式加载机制决定的不是单纯的DAC权限检查。很多人在服务器上用root执行一个没加执行权限的脚本失败后第一反应是去看SELinux其实更大概率就是脚本缺了x位。2. chmod与chown动手改权限前必须掰清楚的细节2.1 chmod的符号模式与数字模式怎么选chmod有两个常用的表达方式符号模式如chmod ux file和数字模式如chmod 755 file。符号模式下u代表属主、g代表属组、o代表其他人、a代表全部三者。加号表示增加权限减号-表示移除权限等号表示只保留指定权限、其他权限清零。日常运维中最香的操作是chmod -R urwX /data里的那个大写X它表示只给目录加执行权限或者给原本已有执行权限的文件加执行权限不会误伤普通文件、让所有文件都变成可执行。这个东西在批量调整网站目录权限时简直是神器用好了能省大量时间避掉把文本文件全部加x的尴尬。数字模式则是把r计为4、w计为2、x计为1三者相加得到一组权限数字。755即属主rwx、属组r-x、其他r-x。644即属主rw-、属组r--、其他r--。600即只有属主能读写。700即只有属主能读、写并执行。记住这个换算规则后不要死记硬背组合而是要学会按需求拼权限位。不要动不动就上777这句话我说过无数次。777意味着任何用户都能读、写、执行这个文件或目录。在Web目录里给了777等于把文件内容、上传目录的写入权、甚至脚本执行权全部交给服务器上任何一个有shell权限的用户。很多VPS被挂马、被篡改首页的案例路径往往是某目录777→ 低权限用户能写入 → 传入webshell或篡改文件 → 被拿到执行权限。真正需要777的场景极少基本只有临时共享一个目录时才考虑而且用完马上要收权。2.2 chown把属主属组改对心里才算有数chown控制这个文件归谁。语法是chown 属主:属组 目标例如chown www:www /data/www/site。也可以只改属主或属组chown -R www /data是递归地把属主改成www属组不动chown :www /data则只改属组。注意:前后两者都写时分隔符是冒号老手常简写为chown www.www但现在的Linux发行版更推荐冒号写法兼容性更好。递归chown -R在高目录数的站点上会有明显耗时尤其是包含海量小文件的缓存目录。我在某站迁移时用chown -R跑了一遍/data/www花了将近二十分钟。后来学聪明了新上线业务直接把应用目录和数据目录在创建时就规划好属主属组再配合后面要讲的umask和SGID从源头上避免大规模递归改属主这种体力活。改属主前还要想清楚一个身份账户问题你到底让哪个系统用户来充当这个目录的属主很多Web服务的实践是创建一个专用账户比如www、nginx、php-fpm然后把站点目录交给这个账户。如果目录属主是rootPHP-FPM进程是www用户那这个PHP进程往目录里写文件时就会因为既不是属主、也不在属组里的尴尬身份撞上权限墙。这几乎是新手最常遇到的我明明改了权限为什么还是写不进去的核心原因之一。2.3 目录权限对文件访问的层层限制一个真实场景我处理过一个典型的例子某同学的站点/var/www/html下有个upload目录权限是755里面文件权限是644属主是www:www。他反映说我上传的图片其他人打不开提示403。我让他看目录权限确实没有755但他把文件权限提到666照样403。原因就在于静态文件服务中Nginx的worker进程通常以非root用户运行worker要打开这张图片先要能穿过/var/www/html和/var/www/html/upload这两层目录任何一层的x权限缺失都会让路径解析失败表现就是403而不是404。通过这个场景可以提炼出一套思路排查文件访问问题永远从进程身份 路径逐层权限这个二元组入手。也就是说先明确真正访问文件的是哪个用户Nginx worker、PHP-FPM进程、SSH登录用户再沿路径从根目录一步步用namei -l或ls -ld检查每一层的权限。这个思路被我在几个项目里反复验证几乎能定位90%以上的文件没权限问题。3. SUID、SGID、Sticky Bit三个被低估的特殊权限3.1 SUID把执行身份临时切换原理与典型案例普通用户运行passwd修改自己的口令时能去写/etc/shadow这个文件平时只有root能读写。为什么普通用户可以因为/usr/bin/passwd文件上设置了SUID位属主权限中的s如-rwsr-xr-x含义是当任何用户执行该程序时进程的有效用户ID临时变为文件属主——也就是root。于是普通用户执行passwd的瞬间该进程拥有了root身份可以写shadow但程序内部的逻辑会严格限制你能改的条目只允许改自己的密码项。SUID是双刃剑。如果某个二进制或脚本被错误地设置了SUID且属主是root那任何一个能执行它的用户都可能借助该程序获得root权限。检查系统里有哪些带SUID的文件可以用find / -perm -4000 -type f 2/dev/null已经发现可疑条目时用chmod u-s 文件名或chmod 755 文件名去掉SUID位。我见过某些同学为了图省事手动给一个Web上传目录的PHP解释器加SUID这种操作等于把服务器后门焊死在系统上务必果断清除。3.2 SGID与协作目录和SUID类似SGID作用于目录时有个非常实用的特性在该目录下新建的文件或子目录自动继承该目录的属组而不是创建者的主组。也就是说只要把我账号和你账号都放进同一个组dev再把协作目录/srv/shared的属组设为dev并加上gs那么不管我们俩谁在里面创建新文件它的属组都会是dev而不是各自的主组。这样同组的同事就能按组权限互相访问文件了。实际用法chmod 2770 /srv/shared其中2代表SGID位。权限显示为drwxrws---。需要注意SGID只是让新文件继承属组新文件的具体read/write权限仍受umask影响所以跨用户协作时通常还要搭配ACL后面详述来控制每个成员的细粒度权限光一个SGID往往不够用。3.3 Sticky Bit怎么保住了/tmp的安全/tmp为什么默认是drwxrwxrwt因为tSticky Bit限制的是谁能删除文件。没有Sticky Bit的共享写目录里任何有写权限的用户都能删除别人创建的文件带来的后果不堪设想。加了Sticky Bit后只有以下三者能删除文件文件属主、目录属主、root。这就是为什么/tmp能让所有用户写入却不让他们乱删别人东西的底层原因。手动设置Sticky Bit用chmod t /目录或数字模式chmod 1777 /目录。在搭建多用户临时共享目录时我习惯用1777的变体比如把w位去掉或者改成1733之类更严的写法避免目录对所有用户完全敞开写入。如果项目需要一个大家都能放临时文件、但不能互相删的目录Sticky Bit几乎是唯一的标准解。3.4 特殊权限位的数值表示与统计查看特殊权限不是额外加三个数字那么简单它们其实是数字模式的第一位4SUID、2SGID、1Sticky Bit组合可以并存如6SUIDSGID。所以4755表示SUID7552755表示SGID7551777表示Sticky Bit777。查看时ls -l会在权限位中显示对应字母SUID是属主位的s或SSGID是属组位的s或SSticky是其他人位的t或T。小写字母表示对应x位同时存在大写字母表示对应x位不存在。比如-rwsr-xr-x是SUID且属主有x-rwSr-xr-x是SUID但属主无x后者对可执行文件而言往往说明SUID设错了因为根本没有x权限位程序无法被正常执行。对于没有可执行权限的文件设置SUID不仅会让ls显示很怪还会被安全扫描工具标记为无效SUID。这种设置没有实际效果但会让审计日志报警属于运维里典型的画蛇添足。4. umask新文件权限默认值的最后一层把关4.1 默认权限的诞生过程Linux创建新文件时权限不是凭空来的。普通文件的基准权限是666因为本地创建的文件不需要默认带执行权限目录的基准权限是777因为目录必须带x才能进入。然后系统用umask把对应位清零。umask并不是从基准权限里减去一个数字这么简单。严格说是对基准权限位与umask取反后的掩码做按位与最终权限 基准权限 ~umask。举例umask022时文件得到666 ~022 644目录得到777 ~022 755。umask002时文件得到664目录得到775。umask077时文件得到600目录得到700几乎把同组和其他人的门全部关死。查看当前umask用umask命令修改临时用umask 027永久改则写入/etc/profile、/etc/bashrc或用户的~/.bashrc。但注意配置文件只在shell登录时生效如果某个服务进程如PHP-FPM、Nginx、Java应用已经起来了它的umask仍是启动那一刻环境变量的值。这也是为什么很多人改了umask后通过Web上传的新文件权限没变——因为Web服务的进程并没有重新读取你的shell配置。4.2 服务进程的umask如何影响站点文件生产环境常见问题PHP-FPM进程以www用户运行新建会话文件或上传文件时默认权限取决于PHP-FPM进程的umask。很多发行版里PHP-FPM的systemd服务默认umask是0022或0027导致生成的文件是644或640。如果你需要同组用户可读写的协作效果可以把PHP-FPM进程的umask改为0002这样新文件会自动变成664目录775。具体改法有两种一种是在php-fpm的pool配置里加umask 0002要求PHP-FPM支持该指令较新版本默认可用另一种是通过systemd服务单元的UMask参数。前者更直观因为只影响对应Pool的worker进程。我一般推荐优先改pool配置因为它精确作用于PHP进程不会误伤其他服务。在调教umask时防住一个常见陷阱umask位是1代表屏蔽该权限所以umask077意味着屏蔽组和其他人的所有权限而umask000表示完全不屏蔽。刚接触的人常常把077误解为把文件权限设为077这是非常普遍的理解错误。顺带一提修改umask后若想验证可以用umask -S查看符号形式。5. ACL常规权限管不了的时候用特批破局5.1 setfacl给指定用户发特批权限常规的u/g/o三组权限面对这样一个场景会很难受某个目录属主是app属组是app但有一个专门的审核账号audit需要读取该目录下的日志文件又不希望把audit加进app组以免它获得组的全部其他权限。这时ACL就派上用场了。给单个用户追加具体权限用setfacl -m u:audit:r-- /data/logs/app.log对该用户查看用getfacl /data/logs/app.log。效果是当内核检查该用户对文件的实际访问权限时会先检查ACL是否包含针对该用户的规则有则以此为准不再看traditional group位。ACL的优先级高于普通属组权限这是很多人排查时容易忽略的黑盒。用ACL管理共享目录时最实用的一个组合拳是在目录上设置默认ACLdefault ACL让新建的文件自动继承指定的ACL条目用setfacl -m d:u:shared:rwx /srv/team。这样团队成员在目录里创建的每个新文件都会自动附加shared用户的相应权限彻底免去反复用chown和chmod去修新文件的麻烦。5.2 chattr i 与acl 的互补作用ACL控制的是用户访问权限而chattr控制的则是文件属性位是比权限位更底层的开关。最常用的是iimmutable文件被加上i属性后即使root也不能修改、删除、重命名甚至连增加硬链接都被禁止。想移除用chattr -i。这个属性对付日志被误删备份脚本跑飞关键配置被改坏都相当好用。我在生产环境给/etc/hosts、/etc/resolv.conf、/etc/shadow以及/var/log下某些关键审计日志加过i配合权限位一起隔离效果显著。注意chattr加锁前务必确认系统启动不需要动态修改这些文件否则可能导致某些依赖动态hosts或动态认证的组件出现异常。例如某些云主机初始化脚本会临时修改/etc/hosts被i锁死之后初始化就会卡住别问我怎么知道的。lsattr可以查看文件的属性位。如果某文件明明没有ACL和权限问题却还是删不掉、改不了先看一眼lsattr大概率就是被i或aappend-only只允许追加锁住了。6. 一整套Permission denied排查流程从经验到方法论6.1 排障前的清单先收集现场信息别急着动手遇到任何权限报错我的第一反应是收集现场信息而不是直接改权限报错时是哪个进程、哪个用户在操作通过ps aux / grep 进程名确定运行身份。操作对象是文件还是目录完整路径是什么完整报错是Permission denied还是Operation not permitted前者是权限位后者通常涉及chattr属性或SELinux。文件的属主属组和权限位是什么逐层目录权限又如何是不是有ACLgetfacl一眼扫过去就能确认。文件是否有特殊属性lsattr看一眼。是否被SELinux或AppArmor拦截临时用getenforce看状态。你看到问题了吗很多改权限没用的案例本质上是根本没走到DAC这一层在SELinux那一步就被拦下了。举个真实案例某站点上传文件时一直报No such file or directory或Permission denied检查发现确认Nginx上传目录权限是755、属主为www:www完全正常。最后查SELinux发现httpd_sys_rw_content_t上下文缺失用restorecon -Rv修复或chcon -t httpd_sys_rw_content_t打上标签后问题立刻消失。从这个案例可以看出来权限排查不能只盯着ls -l那一列系统安全上下文要靠ls -ldZ来看。6.2 真实场景一次缓存目录写不进去的完整排查链路某同学反馈他的站点后台设置界面报缓存目录不可写进展都快崩溃了。他试着把整个目录chmod -R 777 /data/www/caches依然报错于是来问我。第一步我让他先停了那个PHP-FPM进程,用ps aux | grep php-fpm查看master和worker是谁确认worker用户是www。第二步查看/data/www/caches的属主结果是root:root权限755。到这里问题已经很明显www用户不是属主也不在root组对目录拥有的是其他用户权限也就是只有r-x没有写入能力。第三步为什么chmod -R 777没救回来因为该用户当时改了目录权限但目录下某些子目录和session文件可能之前就被chown到了别的属主或者有着奇怪的ACL规则递归777没有连带修正属主与ACL。后来我让他chown -R www:www /data/www/caches并回收权限为2750配合SGID让新文件自动继承属组再在PHP-FPM pool里配置umask0002问题迎刃而解。这个案例的价值在于777只能开放权限但如果写不进的根本原因是属主和身份不匹配、而不是权限位不够那777就是无效的。把身份和权限位两个维度同时检查才是根治问题的做法。6.3 防御性权限设计从源头少踩一半的坑与其反复出问题反复修不如一开始就按最小权限身份隔离的思路来设计目录结构。创建系统用户时给Web服务专用账号如www并指定-s /sbin/nologin让该账号仅用于进程运行不能直接SSH登录。数据目录和应用目录分开例如/data/www放站点/data/logs放日志不给应用写日志目录不必要的大权限。应用目录的惯用权限目录2750、文件0640调整umask为0027可实现或0750加ACL按需放开避免777和666。对关键配置文件加chattr i防止手滑覆盖或被恶意篡改。对上传目录单独设置ACL一般只给所需账号加rwx或rw-不扩大到整个用户组。定期用find扫系统里设置了SUID/SGID的可疑文件用getfacl抽查共享目录的ACL是否与预期一致。这些习惯养成之后你会发现权限报错的频率会断崖式下降。7. 结尾从会改权限到懂权限的关键跳跃我在实际排查中还有一个体会很多人掌握了所有命令却仍然被权限随机爆炸折磨根本原因是没有建立身份-路径-权限-上下文四元组的思维方式。每看到一个权限报错脑子里应该同时闪过这几个问题现在是哪个用户在操作他要穿过哪些目录目标文件和目录的权限位、属主属组、ACL、属性位分别是什么系统安全上下文是否放行把这一套流程走一遍大多数Permission denied都能在两分钟内定位剩下的80%时间里你其实是在用逻辑排除各种可能性而不是在盲目改权限。最后再分享一个小技巧每次修改完权限立刻用操作者的身份去实际执行一次关键操作来验证比如su - www -c touch /data/www/caches/.test不要只盯着ls -l输出自我感动。这个小习惯帮我挡住了无数次改完权限却忘了验证的尴尬。希望这篇梳理对你有用少走弯路。
