我到现在还记得自己刚接触Linux时，第一次被Permission denied折磨的那个下午。明明文件就在眼前，cat一下就是不行，ls -l看列表却又什么都看不明白，上网搜"linux提升文件夹权限命令"，抄了一堆chmod 777，结果安全又被打回原形，后面被一顿喷才意识到问题出在没有真正理解权限机制。
很长一段时间里，很多人对权限的理解停留在"不行就777，再不行就sudo"的层面。作为过来人，我可以直接说：这样的习惯迟早会给你埋坑。一个Web项目被上传漏洞拿到webshell，一个普通用户能改写系统关键目录，或者反过来——部署一个服务半天起不来，结果发现是运行用户没有目录的执行权限。权限这套东西，用不好是安全漏洞，用不对是服务故障，但搞明白了，它就是Linux给你的最直观、最强大的管理工具。
这篇文章就围绕"提升文件夹权限"和"修改文件夹及文件权限的命令"展开，讲清楚chmod、chown、chgrp这几个主兵器怎么用，讲明白sudo和su在"提升"这件事上到底扮演什么角色，最后再聊聊特殊权限位和umask这两个新手最容易忽视的细节。适合刚接触Linux、被权限问题困扰的人，也适合那些已经会用chmod 777但始终没弄懂原理的朋友。
1. 权限模型：先看清rwx和三组九位的门道
1.1 一条ls -l输出里的全部信息
真正读懂权限，得从ls -l的输出开始。随便一个目录下执行，你会看到类似这样的东西：
drwxr-xr-x 3 deploy deploy 4096 Mar 15 10:30 app -rw-r--r-- 1 deploy deploy 220 Mar 15 10:31 config.yml -rwxr-xr-x 1 deploy deploy 512 Mar 15 10:32 run.sh第一列就是权限字符串，看起来像乱码，其实结构非常规整。第一个字符是文件类型：d表示目录（directory），-表示普通文件，l表示符号链接，还有c、b分别对应字符设备、块设备，这些见得少，先不管。
后面的九个字符分成三组，每组三位，从左到右依次是所有者（user）、所属组（group）、**其他用户（other）**的权限。每组里的三位分别是r（读）、w（写）、x（执行），没有权限就显示-。
所以rwxr-xr-x拆开看就是：
| 位置 | 所有者权限 | 组权限 | 其他用户权限 |
|---|---|---|---|
| 字符 | rwx | r-x | r-x |
| 含义 | 可读可写可执行 | 可读可执行，不可写 | 可读可执行，不可写 |
这里有个大多数新手都会懵的地方：目录的r、w、x含义跟文件不完全一样。对一个目录来说，r决定你能不能列出目录内容（即ls），w决定你能否在这个目录里新建、删除、重命名文件，x决定你能不能进入这个目录（即cd）以及访问目录内文件的元数据。
打个比方：目录的x权限是你的"通行证"，r是"一览表"，w是"动手权"。只给目录r不给x，你看着里面文件名但进不去，反而最别扭。
这也是为什么chmod -R 644这种操作会把目录改废——后面会专门讲这个坑。
1.2 为什么权限数字是4、2、1
你肯定见过chmod 755这种写法，但很少有人真去想过三个数字怎么来的。其实r=4、w=2、x=1不是随便定，它对应二进制位：
- 4 = 2²，二进制
100，代表读位 - 2 = 2¹，二进制
010，代表写位 - 1 = 2⁰，二进制
001，代表执行位
把三个权限位累加，就得到这一组权限的八进制数。xx 比如rwx是 4+2+1=7，r-x是 4+0+1=5，r--是 4，---是 0。
因此chmod 754的意思就是：所有者rwx、组r-x、其他用户r--，对应二进制111 101 100，三组权限清清楚楚。这也是为什么这类命令去掉了繁琐的逐位判断，可以用三个数字表达完整权限集合，比任何英文参数都简洁。
理解了这套映射关系之后，看常见的权限组合就一目了然了：
| 权限值 | 所有者 | 组 | 其他用户 | 典型用途 |
|---|---|---|---|---|
| 644 | rw- | r-- | r-- | 普通文件默认，别人只能看不能改 |
| 755 | rwx | r-x | r-x | 目录/脚本，组和其他可读可执行但不可写 |
| 700 | rwx | --- | --- | 私有目录，只允许所有者自己进出 |
| 600 | rw- | --- | --- | 私密文件，比如密钥 |
| 666 | rw- | rw- | rw- | 所有用户可读写，一般不推荐 |
| 777 | rwx | rwx | rwx | 所有用户完全控制，除非临时共享否则别用 |
2. chmod实战：数字法与符号法的选择和混搭
2.1 数字法：一条命令改完三组权限
数字法最大的优势是一次性把三组权限写清楚，语义稳定，执行结果可预测。比如给一个部署目录app设置成所有者可读写执行、组和其他只读可执行：
chmod 755 app如果要连目录里的所有文件和子目录一起改，加-R：
chmod -R 755 /home/deploy/app注意这里的-R是递归（recursive），它会对目录里每一个文件和子目录都执行同样的权限变更。这也带来了一个经典问题：文件和目录需要不一样的权限策略——通常文件644、目录755，但-R 755会把所有文件也带上执行位，虽然不影响使用，但不够干净。
我自己的习惯是，在需要全量调整时用find区分开：
find /home/deploy/app -type f -exec chmod 644 {} \; find /home/deploy/app -type d -exec chmod 755 {} \;-type f只匹配普通文件，-type d只匹配目录，再各自动作，两行搞定，文件不带执行位，目录带上执行位，逻辑上严丝合缝。
2.2 符号法：只改某一组或某一种权限
数字法虽好，但有些场景下你并不想关心其他两组权限现状——你只想"给所有用户加上执行权限"或"把组权限里的写权限去掉"。这时候用符号法更顺手。
符号法的基本格式是：chmod [对象][符号][权限] 文件。
对象有三个字母：u（所有者）、g（组）、o（其他用户），a表示all即三者都包括。符号有三个：+增加权限、-减去权限、=精确设置权限。权限自然就是r、w、x。
举例：
# 给所有用户添加执行权限 chmod a+x run.sh # 去掉其他用户的写权限 chmod o-w config.yml # 给所有者和组读、写权限，但不改变其他用户的权限 chmod ug=rw project.conf # 同时给所有者加执行权限、去掉组的写权限 chmod u+x,g-w build.py符号法适合"增量调整"，比如你只想让当前用户有一个脚本的执行权限，而不是把整个文件权限重排一遍。每次改动只影响你指定的部分，其他保持原样，这在调试过程中特别省心。
2.3 递归改权限的两个经典坑
坑一：目录失去x权限后整棵目录树不可访问。前文说过目录的x是通行证，当你执行chmod -R 644 somedir，所有目录的权限也变成了rw-r--r--，即没有执行位。这时候你cd somedir会报Permission denied，哪怕你ls能看到名字也进不去，Web服务、部署脚本全部跟着挂掉。修复方法是重新给目录加x：
# 目录重新加上执行权限 find somedir -type d -exec chmod +x {} \;坑二：-R对符号链接的处理往往不符合直觉。默认情况下，chmod -R会跟随符号链接指向的目标文件去修改权限（实际上解释器不同行为也有差异，多数发行版默认不跟随命令行中显式给出的符号链接），如果不注意，可能把链接指向的重要文件权限改了而不自知。稳妥的做法是给符号链接目标单独设置权限，命令行里显式操作目标文件，或者使用-h修改符号链接自身的权限（不过符号链接自身的权限通常没有实际作用，真正的限制在目标上）。
3. chown与chgrp：权限给对了人才能生效
3.1 什么时候必须换所有者
chmod只能改"权限大小"，不能改"权限属于谁"。遇到下面这类情况，光靠chmod解决不了问题：
场景A：你以普通用户上传了一个Web项目到服务器，结果发现所有文件的所有者都是这个普通用户。Web服务运行用户是nginx（或www-data、web等，取决于发行版），它需要读项目文件——如果文件权限是600，其他用户一概不能读，那服务自然读不到，页面永远报错。这时候你要做的不是chmod 777把文件贡献给全世界，而是把文件归属调整给部署用户，或者调整到同一个组再给组读权限。
场景B：用root解压了一个压缩包，里面所有文件所有者都是root，普通用户在自己目录里看着这些文件却改不了，必须先把所有权还给自己。
这类问题的核心是让正确的用户/组获得文件的使用权，由chown和chgrp负责。
3.2 chown命令的细节与常见写法
基本语法：
# 只修改所有者 chown deploy app # 同时修改所有者和所属组 chown deploy:deploy app # 只修改所属组（等价于chgrp） chown :devteam app # 递归修改 chown -R deploy:deploy /home/deploy/app注意:和.这个细节：老命令里用chown deploy:deploy，现代写法多数也接受chown deploy.deploy，但为了可移植性和避免歧义，推荐统一用冒号。
另外两个实用参数：
# 参考某文件的owner/group设置 chown --reference=otherfile app # 修改时显示处理的对象（调试递归时好用） chown -R -v deploy:deploy /home/deploy/app-v会把每一个被修改的文件打印出来，配合-R在批量操作时能清晰看到影响范围，避免"以为改完了结果漏了某个子目录"的尴尬。
3.3 换主过程中的安全注意
第一，谨慎使用通配符。chown -R加通配符是误操作重灾区。比如你执行chown -R deploy:deploy /home/deploy/*，如果当前目录匹配到了部署目录之外的文件，就会静默改掉不该动的对象。我的建议是：先ls -l确认范围，再用find ... -exec配合-print预先列举清单，最后才真正执行。
第二，不要图省事把普通目录所有者设成root，还指望业务用户往里写文件。很多人遇到权限报错，第一反应是把目录chown root:root后加777。这等于把保险箱门焊死又给所有人配钥匙——没有意义。正确思路是：目录归谁管理，就chown给谁；多个用户协作，就建一个公共组，chown :group+ 组可写权限。
第三，换所有者之前确认用户是否存在。chown deploy:deploy时如果deploy用户不存在，命令会直接报错，并不会默默执行。这反而保护了你。
4. 提升权限：sudo与su在"提升"里的真实分工
4.1 两种"提升"的本质区别
回到标题里的"提升文件夹权限"。很多人把"提升权限"理解成"我要变成root"，其实这里有两种层次：
第一层是对文件/目录本身执行chmod、chown——这需要你有修改目标对象的身份能力。也就是说，目标资源的所有者是你，你才能随意改；不是你的，就算你能sudo，改的时候也要先考虑清楚有没有必要用管理员身份去动别人的文件。
第二层才是"我当前用户权限不够，需要临时拿管理员身份才能执行某个命令"。典型场景：系统文件在/etc下，普通用户不能改，要执行vi /etc/nginx/nginx.conf，就需要用sudo或者切换到root用户。
4.2 sudo：最小授权的实操配置
sudo的全称是 "substitute user do"，它允许授权用户以其他用户身份执行命令，默认配置下是以root身份运行。
日常使用：
# 以root身份执行命令 sudo chmod 755 /etc/nginx/conf.d/app.conf # 以其他用户身份执行命令 sudo -u deploy whoami配置在/etc/sudoers文件里。注意：不要直接用vi改这个文件，要使用visudo命令。visudo会在保存前做语法检查，写错了不会让你把系统锁死，这个保护非常关键。
最简单的授权写法，把某用户加进wheel或sudo组：
usermod -aG wheel deploy # 不同发行版组名不同，常见是 wheel 或 sudo效果上，该用户就可以通过sudo执行管理员命令。但这种"全量sudo"权力很大。某些生产环境里，你想给某个用户限定"只允许执行某几条权限相关命令"（比如只允许它执行chown和chmod，不能干别的），可以在sudoers里这样配：
deploy ALL=(root) /bin/chmod, /bin/chown意思是用户deploy在任意主机上，可以以root身份只执行/bin/chmod和/bin/chown这两个命令。他没法执行visudo、passwd这些敏感命令，避免权限被进一步放大。
4.3 sudo和su怎么选
su是切换用户，通常是从普通用户切到root，切过去之后整个shell环境都变成root，后面每一条命令都具有管理员权限。相比之下，sudo只提升单条命令的权限，执行完就回到普通用户身份。
两者选择很简单：
- 只跑一两条管理员命令 →
sudo，用完即走，风险面小。 - 需要连续做一系列管理操作，且你知道自己在干什么 → 可以
su，但务必操作完立刻exit回普通用户。
我见过不少人要么什么都是sudo bash挂个root shell干完忘记退，要么在生产里常年开着root终端。这种习惯一旦操作失误，后果往往是全局性的。遵守一个原则：权限给到最小，时长给到最短。
5. 特殊权限位与umask：决定权限下限与隐藏陷阱
5.1 setuid、setgid、sticky bit
普通的rwx之外还有三个特殊权限位，用数字法表示时，通常写成四位，比如4755、2770、1777。它们分别对应：
| 数字 | 英文名 | 作用 | 常见场景 |
|---|---|---|---|
| 4 | setuid | 文件以所有者的身份运行，而不是执行者的身份 | 二进制程序需要临时获得特殊权限 |
| 2 | setgid | 文件以所属组的身份运行；对目录而言，新建文件自动继承目录的组 | 共享目录多用户协同时特别有用 |
| 1 | sticky bit | 目录下文件只能被所有者或root删除，其他人即使有写权限也删不了别人的文件 | /tmp目录默认就是这种 |
典型例子是/tmp目录，ls -ld /tmp你会看到drwxrwxrwt，最后一个t就是 sticky bit。设置命令：
# 设置setuid chmod 4755 some_binary # 设置setgid到共享目录 chmod 2775 /home/dev/shared # 设置sticky bit chmod 1777 /data/tmp特别注意：setuid 对脚本（shell脚本、python脚本）是无效的，因为解释器会忽略这个位，只有编译好的二进制才有实际效果。很多人以为给脚本加4755就能让普通用户以root执行，实测不会有任何变化。另外一个安全警示：如果你的系统里出现了一个root所有的setuid文件，就要警惕了，这类文件经常是提权后门的目标。
5.2 umask：为什么新建文件不是777
还有一个影响权限的隐形因素umask。它决定你新建文件、目录时的默认权限上限，而不是直接给权限。
这个机制很反直觉：它做的是"减法掩码"。系统默认认为普通文件的最大权限是666（因为默认不给执行位），目录是777。然后你把umask里的位从最大权限里"扣掉"。
常见umask 022的效果：
- 新建文件：
666 - 022 = 644，即rw-r--r-- - 新建目录：
777 - 022 = 755，即rwxr-xr-x
如果umask 077：
- 新建文件：
600，只有自己可读写 - 新建目录：
700，只有自己可进入
查看当前值：
umask临时修改：
umask 077持久化修改：在用户配置文件（如~/.bashrc）里加上umask 077，新开的shell都会生效。
值得多说一句的是，这个减法并不是严格的算术减法，而是按位取掩码后的结果，但日常用022、077这种常见值时用算术理解就够了。理解了umask，你才会明白为什么你mkdir出来的目录不是777——不是系统出 bug，而是它在帮你按默认策略做了权限缩减。如果你希望某个目录对组内成员可读写，除了mkdir之后chmod，很多时候更优雅的做法是调低umask再创建，这样后续新建的文件也会自动带上合适的组权限。
最后再分享一点个人体会。权限命令这东西，看起来就那么几个字母，真正上手之后才会发现"精确控制"比"盲目放开"难得多，但也重要得多。我早期踩过的坑主要不是命令记不住，而是懒得想"为什么这个报错是权限问题、到底是缺哪个位"。后来我把ls -l当成默认动作，每次报错先看权限字符串，再判断是缺r、缺w还是缺x，思路就顺了。这个习惯一旦养成了，你回头看那些chmod 777的偷懒操作，会自然产生一种"这太糙了"的感觉。权限不是麻烦，它只是逼你把资源归属和操作边界想清楚。下次再拿到一台服务器，建议你先在关键目录上跑一遍ls -l和getfacl（如果有ACL需求），摸清了再动手。
