1. 先搞明白权限到底在管什么聊Linux权限之前我猜不少读者都有过这种经历新装了个环境把项目代码传上去运行的时候报Permission denied一看文件权限-rw-r--r--心里想的是这不挺正常的吗为啥不让跑然后顺手一个chmod 777问题消失了但根子上的疑惑一直没解开。这篇文章就是把这些根子上的东西掰开揉碎讲清楚适合刚接触Linux的运维新手、被权限坑过的开发者以及想系统梳理一遍权限知识的进阶用户。权限在Linux里不是一个抽象概念它本质上就是内核在打开文件之前做的一道准入检查。你在shell里敲ls -l看到的那一串-rw-r--r--就是这道检查规则的直观呈现。整条规则可以拆成四个部分文件类型、属主权限、属组权限、其他用户权限。前三位是你自己owner的权限中间三位是和你同组的人group的权限最后三位是所有人other的权限。这里面有个很容易被忽略的点Linux权限判断是先匹配身份再应用权限。内核在检查时会先看你是文件的属主吗是的话直接套用owner权限段不再往后看不是的话再看你的主属组是否和文件属组一致一致就套用group权限段如果都不是才落到other权限段。所以一个用户对某个文件的实际权限永远是三段中某一段的结果不存在叠加这回事。至于每个位置上的r、w、x含义也要分开看r代表可以读内容w代表可以修改内容x代表可以把它当作程序去执行。对普通文件来说这三个位比较直觉但放到目录上就完全是另一套语义了。目录的r只决定你能不能列出目录里有什么w决定你能不能在这个目录里新建、删除、重命名文件x决定你能不能穿过这个目录、进入它去访问里面的文件。很多人被目录要x权限才能cd进去搞懵其实只要记住目录的x是通行权没有它哪怕你有r权限cat里面文件依然会报Permission denied。2. 从rwx到数字chmod的两种表示法都要会把权限从符号改成数字靠的是二进制编码。每一位权限对应一个数值r是4w是2x是1。三位的组合就是三组值的加法比如rwx是4217rw-是426r--是4---是0。所以常见的644意思是属主可读写、属组和其他用户只可读755则是属主全权限、属组和其他用户可读可执行。chmod 755和chmod urwx,grx,orx是等价的前者叫数字模式后者叫符号模式。数字模式的好处是简洁一条命令一个数字组合就搞定了适合批量设置和脚本里使用。但理解门槛略高你必须先在脑子里把数字拆回二进制才知道它到底开了哪些权限。符号模式则更直观它用uuser、ggroup、oother、aall指代对象用、-、表示加权限、减权限、精确设置权限。比如chmod gw test.txt的意思是给属组加写权限其他组不动chmod o-x test.txt是去掉其他用户的执行权限。实操里我的建议是日常手动改权限用符号模式因为它更安全、意图更清晰只改你关心的那一个位不会误伤其他位脚本或需要统一重置一堆文件权限时用数字模式写起来利落。还要提醒一句chmod -R递归改权限时一定要先确认目录结构里有没有需要保留特殊权限的文件比如后面要讲的setuid程序一个递归下去很容易把它们的特殊位抹掉而且不会有任何提示。顺带说一个我见过很多次的误区有人以为chmod x是无条件给所有人加执行权限。其实不带u/g/o时chmod x默认作用于a但实际行为会受umask影响不同环境下结果可能有细微差别。想精确给属主加执行权限请写chmod ux。3. 属主和属组chown与chgrp的配套操作文件权限三段里owner和group这两段是跟着文件元数据走的而不是跟随用户走的。修改这两项用的是chown和chgrp。chown既可以改属主也可以同时改属组比如chown alice:dev report.pdf就把属主改成alice、属组改成dev只改属组不想动属主的话可以写成chown :dev report.pdf这和chgrp dev report.pdf是一个效果。日常开发中最容易踩坑的场景是部署代码。很多人的习惯是用root把代码放到/var/www下然后发现应用进程以普通用户运行没法写日志、没法碰上传目录。这时候直接chown -R www:www /var/www才是正解而不是一股脑chmod 777。777意味着任何用户都能读写执行这份代码一旦机器上有其他被攻破的账户或存在恶意用户你的代码和配置就等于完全裸奔了。把属主和属组精确交给运行服务的那个账户是更稳妥的做法。还有一个细节chown操作本身是需要权限的。只有root能做任意chown普通用户即使对文件有完全控制权也无法把文件属主改成别人。这是Linux防止你把自己的文件丢给别的用户然后占用对方的配额或达到某种欺骗目的的策略。但普通用户可以把文件组改为自己所属的组前提是文件的属主是自己。所以很多系统里你会发现普通用户能chgrp但不能chown这背后是同一套安全逻辑。递归改属主也建议用chown -R但和chmod一样先确认符号链接的情况。默认情况下chown会解引用符号链接直接改到链接指向的目标文件如果你只想改链接本身要加-h参数。这个坑在配置文件里藏了一堆软链的场景下尤其容易爆。4. umask新建文件的默认权限是怎么来的很多人在Linux里创建文件后看到的权限是644、755不是满权限666和777就是因为有个叫umask的东西在起作用。umask不是一个命令专属概念它是shell的一个属性决定了进程创建新文件和新目录时从默认权限里去掉哪些位。理解umask的关键在于它是个遮罩规则是新建文件的基准权限是666因为文件默认不该有x权限新建目录的基准权限是777。然后在这个基础上把umask里对应位置出现的权限位扣掉。比如umask是022八进制表示就是--- -w- -w-文件从666里扣掉组写和其他用户写得到644目录从777里扣掉这两项得到755。这里要给大家排一个高频理解错误umask不是用777减掉umask数值这么简单。用减法算常见umask恰好能得到正确结果是因为巧合——二进制位恰好一一对应。但碰上umask为类似011的时候就会出问题777 - 011 766而实际结果应该是755不对实际上目录结果是777 ~011即777去掉组执行和其他用户执行位结果是766。所以正确计算方式是基准权限按位去掉umask中为1的位而不是直接做减法。umask在shell里查看用umask命令修改用umask 022这样的形式。它影响的是当前shell以及后续启动的子进程想永久生效得写进shell的配置文件里比如~/.bashrc。在编写脚本时如果某些临时文件不希望别人看到内容合理做法是在脚本开头设置umask 077这样所有新创建文件的默认权限就是600目录是700可以避免很多临时文件里带着密码之类的意外泄漏。等脚本结束再恢复原来的umask最好用oldmask$(umask); umask 077; ...; umask $oldmask的方式保证可恢复。还有个经验团队协作时如果发现大家创建的文件权限不一致多半是环境里的umask不统一。比如有人设置了umask 002想让组内同事可以互相编辑各自创建的文件而另一个人还是默认022文件就不会被组内其他人写入。这时候与其逐个叮嘱不如在项目仓库里放一个说明文档或者用git hooks统一执行环境的umask设置省得后续排查半天。5. 特殊权限位SUID、SGID、Sticky Bit的实战语义普通的rwx是权限体系的地基真正让Linux权限机制变复杂的是三个特殊位SUIDsetuid、SGIDsetgid和Sticky Bit。它们都出现在x的位置上分别对应rws里的s、rwx组里的s以及目录权限最末端的t用数字模式表示时对应4、2、1三个高位组合成三个字符加在普通三位数字前面比如4755、2755、1777。SUID的作用是当一个具有SUID位的可执行文件被运行时进程的有效用户ID会临时变成该文件属主的ID而不是当前登录用户的ID。最典型的例子是/usr/bin/passwd它属主是root带SUID位普通用户执行它时能以root身份去修改/etc/shadow否则普通用户根本没有写shadow文件的权限也就没法改自己的密码。这个机制设计得很优雅但也非常危险如果系统里出现了一个属主是root且带SUID位、任何人都能执行的程序那就意味着任何用户都能以root身份去跑这个程序一旦程序本身有漏洞整个系统就等于被打开了一道口子。日常巡检时我建议定期用find / -perm -4000 -type f看一下系统里有哪些SUID文件把新增的多余项揪出来。SGID有两种语义。作用于可执行文件时它让进程的有效组ID变为文件属组的ID类似于SUID对组的版本。作用于目录时它带来一个对团队协作极其有用的行为所有在该目录下新建的文件和子目录其属组会自动继承目录的属组而不是创建者自己的主属组。共享工作区里如果想让组内所有成员都能访问彼此创建的文件光靠chmod是不够的因为新建文件默认组是创建者主组你得先chgrp一下。对目录设置SGID就能一劳永逸。比如一个共享目录/srv/team的属组是dev给它设置gs后组员们在里面创建的所有文件自动属于dev组再配合umask 002或者ACL就能实现很顺滑的协作环境。Sticky Bit的应用场景就简单多了它专门用于目录典型代表是/tmp。一个带Sticky Bit的目录里面的文件可以被任何人创建、读取但删除时只有文件属主、目录属主和root能动手其他人即使对该目录有写权限也删不掉别人的文件。这个设计防止了共享目录里我删你文件、你删我文件的恶性循环。用数字模式设置这三个位是在普通权限前加一位数字比如chmod 1777 /tmp符号模式则分别是us、gs、t。注意一下符号模式的chmod t只对目录有意义对文件设置Sticky位在现代Linux上基本没有实际保护作用。检查特殊位的时候你可能会看到rws、rwS和rwx的差别如果s或t是小写说明对应的x权限同时存在如果是大写S或大写T说明设置了特殊位但没有x权限。这种状态在可执行文件上通常意味着特殊位发挥不了作用在目录上则可能引发一些意料之外的行为看到大写的时候建议先确认是不是误设了。6. 不能忽视的检查与调优ACL和sudo的权限边界标准权限三段模型对付不了所有场景。比如开发组里三个人A要读文件、B要写文件、C什么都不给但文件只能有一个属组标准权限就抓瞎了。这时候得用ACLAccess Control List它允许你在标准属主/属组/其他之外再为任意用户或任意组单独指定权限。ACL在大部分主流的Linux发行版上默认是文件系统层面支持的但需要安装acl工具包来操作。核心命令就两个setfacl和getfacl。setfacl -m u:alice:rwx /data/project能给用户alice单独配置对某个目录的完整权限setfacl -m g:dev:rw /data/project能给dev组配置读写权限。加了-R可以递归应用但要注意递归时别把目录本身的ACL也一路套到子目录上必要时可以用-R -m配合-d参数只设置默认ACL。默认ACL这个概念对共享目录特别有用给目录设好default ACL后所有新建的文件和子目录会自动继承这些ACL条目不需要每次手工去setfacl。ACL有个隐藏影响一旦一个文件被设置了ACLls -l的权限位后面会多一个号。在文件上ACL的mask会限制所有命名用户和命名组的权限上限。比如你给alice设置了rwx但mask是r-x那alice实际只有r-xw权限被mask挡住得setfacl -m m::rwx先把mask放开。这个mask经常被忽略排查ACL问题时先看mask往往能直接定位问题。再往上层走sudo是Linux权限体系里另一个重要边界。它解决的痛点是日常操作不应该用root跑但某些操作又确实需要root权限。sudo通过/etc/sudoers文件来精确控制谁能在哪台机器上以什么身份执行哪些命令。配置文件必须用visudo命令编辑它会做语法检查避免你保存了一个无法解析的文件导致sudo全部失效。sudoers的基本写法是用户名 主机名(身份) 命令比如alice ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx意思就是alice可以在所有主机上免密执行重启nginx的命令。NOPASSWD标签很实用但也意味着拿到alice的会话就等于拿到了该命令的执行权所以要严格控制允许的命令范围。更稳妥的写法是限定命令的完整路径并且加上参数白名单别写一个裸的/usr/bin/systemctl那样等于允许任何人操作全部服务。另一个和sudo深度相关的问题是env_reset。sudo默认会重置大部分环境变量只保留少数安全变量这能避免用户通过恶意LD_PRELOAD等环境变量劫持以root身份运行的进程。但也有坑你在普通shell里设的代理、JAVA_HOME、PATH等到了sudo环境里全没了导致某些脚本在sudo下跑不起来。排查这类问题时不要急着改env_keep先看看是不是脚本对PATH等变量有硬编码假设。7. 权限引发的典型故障排查实录最后分享三个实际经历过的权限故障每个都是可以复现教学的好案例。第一个案例某次给Web应用做迁移新环境里上传目录一直报权限错误。ls -l看权限是drwxr-xr-x属主属组是www应用进程也是用www用户跑的怎么看都没问题。后来用namei -l /var/www/html/uploads逐层查才发现问题根本不在最里层而是中间一层目录/var/www的属主是root权限是750www用户没有x权限穿不过去。权限排查记住一句话路径上每一层目录都要有x权限缺任何一层都会以Permission denied收场。namei这个命令挺好用的系统自带的一句话就能看到路径上每一层目录的权限。第二个案例某个共享开发服务器上组员突然发现新创建的文件别人读不了。查了一圈发现有人把umask手动改成了 077且写进了自己的 bashrc。所有从该用户会话创建的文件全都变成600其他组员自然读不了。类似问题最容易出现在多人共用服务器的场景尤其是临时改了umask忘了还原的。最终的根治办法是在共享目录上开启SGIDdefault ACL同时约定组内统一umask为002让权限不依赖个别人的手动操作。第三个案例和SUID相关。巡检时用find / -perm -4000 -type f 2/dev/null发现某个游戏服务器目录里躺着一个带SUID的二进制文件属主是root。一查是某个不知名第三方工具自带的helper安装脚本用了root权限直接解压并且保留了setuid位。这种情况非常危险因为任何人都能执行这个root属主的程序如果它内部有缓冲区溢出或者逻辑后门机器就等于被种了后门。处理方法是立即去除SUID位、删除该文件然后查一遍该工具的来源和安装包完整性。这个案例也说明了一件事永远不要用root去解压来源不明的压缩包尤其别在解压时保留权限属性。8. 权限设计里容易被忽略的细节最后聊几个大家在写脚本、写部署文档时特别容易忽略的权限相关细节。一个是执行脚本时的shebang与x权限关系。如果你写了一个.sh脚本并且用bash script.sh去执行脚本本身不需要x权限只要bash能读就行但如果是./script.sh这种直接执行方式就必须有x权限。部署文档里如果没讲清楚这两者的差异用户常常会在chmod x了为什么还报permission denied上绕半天其实是路径问题或者挂载选项问题。另一个是和挂载选项相关的。如果某个分区挂载时加了nosuid或nodev选项那么即使文件系统里有SUID位它也不会生效。这个特性常被安全加固指南用来防止某个可写分区出现SUID提权漏洞。排查类似问题的时候注意区分文件本身权限没问题和挂载选项限制了权限语义两个层面不要只盯着chmod和chown猛查。还有一个容易被忽略的是SELinux或AppArmor这类LSM模块。很多发行版默认开着SELinux文件权限位都正常但进程依然被拒绝访问这时候往往是SELinux的上下文标签在拦。遇到权限看起来完全正确但就是不行的情况先看/var/log/audit/audit.log有没有AVC拒绝记录或者临时用setenforce 0验证一下生产环境不要实验环境可以ACL和LSM两层机制叠在一起光靠ls -l根本无法看出来全貌。权限设计说到底是一个最小够用的思路能精确到用户就不给组能精确到组就不给所有人能用ACL解决就不开777能用sudo白名单下放就不泄露root shell。把这些原则沉淀到日常习惯里权限相关的故障会减少很多。排查权限问题的时候也不要只盯着文件本身来回chmod逐层检查路径、确认身份匹配、查一下ACL和挂载选项、再看看selinux日志基本就能把所有坑都填平了。
