Linux权限管理全解：rwx模型、chmod命令与ACL实战

做Linux运维和开发的朋友应该都有过这样的经历：刚接触Linux时，最头疼的不是记不住命令，而是搞不清楚权限。明明自己创建的文件，换个用户就进不去目录了；照着网上的教程敲了个chmod 777，结果被老前辈劈头盖脸一顿说。其实权限管理没那么玄乎，它就是你Linux服务器安全的第一道大门，搞懂了它，后面学用户管理、进程管理、容器部署都会顺畅很多。这篇内容就是我从零摸索Linux权限体系后整理的入门总结，适合刚入行的运维新手、转做后端开发的程序员，以及被权限问题折腾过但没系统梳理过的朋友。我会把权限模型、常用命令、默认权限规则、特殊权限位这些核心内容串起来讲，每一块都配上我实际验证过的例子和踩坑记录。

1. 先搞懂Linux权限模型：不是背命令，是理解规则

很多人学权限就是死记chmod 755这种数字组合，但换个场景就蒙了。原因在于没理解Linux权限的底层规则：它到底在管什么、凭什么这么管。

1.1 三类对象与三种权限：把rwx彻底讲透

Linux的权限模型说白了就是“谁”能“做什么”的问题。“谁”被分成三类：文件所有者（u，即user）、所属组（g，即group）、其他用户（o，即others），还有一个特殊身份“所有人”（a，即all）。与之对应的是三种动作：读（r，read）、写（w，write）、执行（x，execute）。

这三种动作的含义，如果你查过资料应该都见过——读就是能查看内容，写就是能修改内容，执行就是能运行它。但这里有个非常关键的细节：对文件和对目录来说，rwx的意义完全不同。我见过太多新手甚至部分老手在这个点上栽跟头。

尤其注意目录的w权限，它管的是“目录里文件名单”的增删改，而不是文件内容的修改。换句话说，只要你对一个目录有w权限，即使目录里的某个文件属于root、你完全没权限修改它，你依然可以把那个文件删掉，因为删除操作动的是目录的名单，不是文件本身。这个特性在多人共享服务器时特别容易被忽略，也是很多“为什么我能删别人的文件”这类问题的根源。

1.2 从ls -l的输出说起：一行字符串怎么读

理解模型之后，得会看实际结果。在Linux下执行ls -l，每一行输出基本长这样：

-rw-r--r-- 1 zhangsan dev 1024 Jan 15 10:30 app.log

这行信息怎么拆？看两部分：开头那10个字符和后面的用户组字段。

开头-rw-r--r--：第1个字符表示文件类型，-表示普通文件，d是目录，l是符号链接，c是字符设备，b是块设备。后面9个字符分成三组，每组三个，依次对应所有者、所属组、其他用户的权限。rw-代表所有者可读可写不可执行，r--代表组内成员只读，最后的r--代表其他用户只读。

后面的zhangsan dev：第一个是文件所有者，第二个是所属组。如果一个用户既不是文件所有者也不属于那个组，他执行任何权限检查时就走“其他用户”那一档。这个概念很基础，但真到排查问题的时候，很多人分不清“当前用户到底命中哪一档”，导致看权限字符串时判断错误。

1.3 权限命中的优先级：别跳档，按顺序来

说到判断逻辑，这里有个隐藏规则值得单独拎出来：系统判断当前用户能对文件做什么时，是严格按顺序匹配的。首先是“我是不是文件所有者？是的话，权限就是所有者那三个位”。如果ls -l显示所有者是你，但所有者权限是r--，你连w都没有，哪怕组权限写的是rw-也没用——因为你已经命中第一档，不会去看组权限。

这个优先级问题在实战里会造成一个很常见的误解：某用户明明在文件所属的组里，组权限也有w，但他就是改不了文件。查了半天发现，文件的所有者恰好就是他自己，而所有者那一档只给了r权限。规则没错，是判断顺序搞错了。所以排查权限问题，第一步永远是ls -n或者id确认身份，再去看对应档位的权限位。

2. chmod/chown/chgrp基础实操：权限三件套的完整用法

理解了权限模型，下一步就是实际操作。chmod改权限、chown改所有者、chgrp改所属组，这三条命令覆盖了日常90%的权限调整需求。

2.1 chmod的两种姿势：符号模式与数字模式

chmod有两种用法，我建议都掌握，因为不同场景下各有优势。

符号模式写起来直观，用u/g/o/a指代对象，用+/-/=来增删或指定权限：

chmod u+x script.sh # 给所有者增加执行权限 chmod g-w,o-r file.txt # 移除组和其他用户的写/读权限 chmod a=rw file.txt # 所有人统一设置为可读可写

数字模式则更简洁。r=4，w=2，x=1，把三组数字相加就得出三位八进制数。755就是所有者rwx（4+2+1），组r-x（4+1），其他r-x（4+1）。这个计算逻辑很简单，但很多新手会疑惑为什么是八进制而不是十进制——因为Linux对权限的处理天然就按二进制位来管理，4、2、1正好对应三个bit位，理解成开关更准确。

7 = 4+2+1，即rwx全开；6 = 4+2，即rw；5 = 4+1，即rx；4 = 4，即只读。这几个数字是高频组合，建议形成肌肉记忆。

chmod 755 script.sh # 典型可执行文件的权限，所有人可执行，只有所有者可写 chmod 644 config.conf # 典型配置文件的权限，所有人可读，只有所有者可写 chmod 600 secret.key # 私密文件，只有所有者可读写

但说句实在话，chmod 777是新手最常用的命令，也是生产环境里最不该出现的命令。把读写执行权限放给所有用户，等于自己拆掉了安全防线。我在处理别人服务器问题时，经常发现一堆777的文件，排查后基本都是当初图省事留下的。

2.2 权限变更的生效细节：chown与chgrp的正确打开方式

chown负责修改文件所有者，同时也支持直接修改所属组，用冒号分隔：

chown zhangsan file.txt # 修改所有者为zhangsan chown zhangsan:dev file.txt # 同时修改所有者与所属组 chgrp dev file.txt # 仅修改所属组为dev

变更所有权时有个细节必须注意：只有root用户才能修改文件所有者。普通用户想把文件所有者改成别人会被拒绝，因为这样等于把自己持有的文件“送给”了别人，系统不允许。但普通用户可以修改自己文件的所属组，前提是他是该组成员且目标组存在。

另外，递归修改时用-R参数，比如chown -R zhangsan:dev /data/app。这里我踩过坑：-R会把目录下所有子文件的一次性改掉，但符号链接默认不会被追踪，需要用-h参数连同链接本身一起改。如果不确定目录里是不是有链接，改完之后用ls -l抽查一眼总没错。

2.3 实操演示：一个多用户项目目录的权限配置

把上面几条命令串起来，我模拟一个场景：某公司服务器的/data/shared目录要交给开发组成员共同使用，每个人创建的文件组内都能读写，但其他无关用户不能访问。

# 先创建目录并重置属主属组 mkdir /data/shared chown root:dev /data/shared chmod 770 /data/shared

配置完了测试一下：dev组的成员A创建了一个文件，默认情况下其他成员可能只有读权限，因为umask默认值是022。要让同组成员都能编辑，简单粗暴的办法是在每次创建文件后手动chmod g+w，但更科学的方案是用后面要讲的SGID位和默认ACL。这里先记住一个结论：目录权限定好只是第一步，文件级别的权限继承要靠特殊权限位和ACL来配合。

3. umask与默认权限机制：新文件为什么总是644

有没有人好奇过，为什么touch出来的新文件总是644，mkdir出来的目录总是755？这就是umask在起作用。它不是什么高深概念，但确实有一层窗户纸。

3.1 umask的计算方法：不是减法，是掩码

先看当前值：

umask # 输出通常为 0022

umask机制简单说就是一套掩码规则。新建文件的默认权限应该是666（rw-rw-rw-，即所有人可读写），新建目录应该是777（rwxrwxrwx，因为目录需要执行权限才能进入）。然后用默认权限减去umask值就是最终权限。

666 - 022 = 644 # 文件 777 - 022 = 755 # 目录

但这里有个特例，-不是真正的减法，而是按位掩码。umask 022意味着二进制第2位（属组写权限）和第5位（其他用户写权限）被清掉。比如你要创建的文件需要执行权限，umask为022时，666-022确实等于644。但如果是某些安装脚本里临时生成的可执行文件，即使指定了mode 777，往回减022得到755，依然能执行。这个性质在写安装脚本时要注意：别以为明确给了777最终就一定是777，系统会自行应用umask过滤。

3.2 临时修改与永久修改：登录shell配置

临时调整就在当前终端执行：

umask 002 touch test.txt # 新建文件权限为 rw-rw-r--，也就是664

永久修改要看shell配置。常见发行版的全局配置在/etc/profile或/etc/bashrc，用户独立配置在~/.bash_profile或~/.bashrc。建议普通用户在自己的~/.bashrc里加umask 002来让同组协作更顺畅，但生产环境多人共用服务器时，保守起见保持022更安全。

3.3 umask相关的常见困惑

有人会在/etc/profile里看到umask 022，又在/etc/bashrc里看到不同的值，纠结到底哪个生效。其实它们存在不同的启动阶段和文件中，谁的优先级高取决于shell启动流程，一般用户级~/.bashrc的配置会覆盖全局。真搞不清的时候，登录后在终端直接敲umask看实际值最直观。

另一个常见坑是umask影响范围：它只影响当前shell及其子进程新建文件时的默认权限，不影响已经存在的文件。所以你在服务器上建了很多文件之后突然调整umask，老文件权限不会有任何变化。

4. 特殊权限位：SUID、SGID、Sticky Bit

标准rwx之外还有三个特殊位，它们存在的意义都是解决特定场景下的授权难题。入门阶段不求全部精通，但至少要认识它们，因为生产环境里几乎天天碰到。

4.1 SUID：为什么普通用户能改密码

先看一个经典问题：/etc/shadow里存的是用户密码哈希，权限是-rw-------，只有root能读写。但普通用户执行passwd却可以修改自己的密码，那passwd是怎么写入shadow文件的？

答案就是SUID位。看ls -l /usr/bin/passwd，输出是：

-rwsr-xr-x 1 root root 63736 ... /usr/bin/passwd

所有者权限那组的x变成了s，这就是SUID位。它的机制是：当普通用户执行带SUID位的程序时，进程的有效身份临时提升为该文件所有者的身份。既然文件所有者是root，进程就拥有了root权限，能访问/etc/shadow。

给普通二进制文件设置SUID是极其危险的操作，等于给一个白名单用户开了后门。比如把/bin/bash设置成chmod u+s /bin/bash，任何用户执行bash都会得到root shell。我见过有人为了图方便这么干，结果被扫描到并利用，服务器当场失守。

4.2 SGID：目录协作共享的经典方案

SGID位有两个层面的作用。作用于可执行文件时，进程的有效组身份会切换为文件的属组；作用于目录时，特性更实用——目录下新建的文件或子目录会自动继承该目录的所属组，而不是创建者自身的默认组。

chmod g+s /data/shared ls -ld /data/shared # 输出 drwxrws--- ... 组权限的x变成了s

这正好解决了前面第2章的问题：当所有开发组成员对/data/shared目录有写权限时，A上传的文件默认属组是A的私有组，B再想编辑就要看权限够不够。加了SGID之后，目录内所有新建文件的属组自动变成dev，配合组权限的rw，就能让同组成员互相编辑文件，而且文件所属组始终统一。可以说SGID是早期Linux多人协作方案的基石。

4.3 Sticky Bit：/tmp目录的安全护栏

Sticky Bit位最典型的应用在/tmp目录。看ls -ld /tmp输出：

drwxrwxrwt 1 root root ... /tmp

其他用户权限的最后一位t，就是粘滞位。它的作用是：目录下任何人都能创建文件，但只有文件的所有者（或root）才能删除自己的文件。没有这个位的话，由于/tmp是全用户可写的，A创建了一个临时文件，B随时可以把它删掉——这在多用户系统是无法接受的。

在共享调试目录、项目临时目录上，善用Sticky Bit可以避免很多团队协作中的“灵异”问题。设置方法：

chmod o+t /data/tmp_shared # 或 chmod 1777 /data/tmp_shared

特殊权限位在数字模式下有独立的权重：SUID=4，SGID=2，Sticky=1，放在rwx数字前面，比如4755、2755、1777。但写权限组别时，如果原位置没有x权限，特殊位会显示为大写的S或T，实际效果是特殊位“挂空”，需要注意。

5. ACL访问控制列表：权限位的补充方案

标准权限只有u、g、o三档，真实场景经常不够用。比如某个文件只允许用户A和管理员访问，A不在文件所属组内，又不想给所有组用户开权限——这种场景就该上ACL了。

5.1 为什么需要ACL：rwx模型的局限性

传统权限模型有一个天然短板：它只能配置一个所有者、一个所属组、一个其他用户。如果权限需要按人员细粒度分配，就不得不断创建新组来适配。组一多，管理复杂度直线上升，而且很多人容易在组权限的归并中出错。

ACL全称Access Control List，可以给任意用户或组单独设置权限，而且不破坏原有三档模型。它在文件系统层面被实现为扩展属性，统计、备份时容易遗漏。

5.2 基本用法：setfacl与getfacl的组合拳

看当前ACL：

getfacl /data/shared/report.pdf

输出正常会包含文件属主、属组、掩码这些字段。设置ACL：

setfacl -m u:lisi:rw /data/shared/report.pdf # 给lisi单独设置读写权限 setfacl -m g:auditors:r /data/shared/report.pdf # 给auditors组设置读权限

查看修改后的ls -l结果，权限位后面会多一个+号，比如-rw-rw----+，提醒你这是带扩展ACL的文件。

删除特定ACL：

setfacl -x u:lisi /data/shared/report.pdf

清空全部ACL：

setfacl -b /data/shared/report.pdf

5.3 默认ACL的继承：让协作目录一劳永逸

到这里可以回答第2章遗留的问题了：如何让/data/shared下新建文件自动继承团队权限？用默认ACL就能解决：

setfacl -d -m u:lisi:rw /data/shared setfacl -d -m g:dev:rwx /data/shared

加了-d之后，后续在该目录新建的文件会自动带上lisi和dev组权限。但注意，默认ACL只影响新建文件，对已有文件不生效。所以如果目录里已有历史文件，要么逐个补一遍，要么先改造目录再重建数据。

用ACL有个很猥琐的坑，就是mask字段。设置了ACL后，getfacl输出里那个mask值就像红绿灯，限定所有命名用户和命名组的最大权限。比如mask为r--，那么哪怕你给lisi设了rw，实际生效也只是r。排查ACL权限问题时一定要先看mask，别一上来就怀疑setfacl写错了。

6. 一个多用户场景的权限规划实战

光讲命令容易流于表面，我再用一个完整案例把这套体系串起来。某公司一台应用服务器，目录结构如下：

/data/app/ # 放后端服务代码，需要对运维开放读写，对开发只读 /data/shared/ # 开发组共享目录，组内完全共享，其余人不可见 /data/logs/ # 服务日志，运维可写，开发可读

我当时的规划流程是这样的：

groupadd devops groupadd dev mkdir -p /data/{app,shared,logs} chown -R root:devops /data/app chmod -R 750 /data/app chown -R root:dev /data/shared chmod -R 770 /data/shared chmod g+s /data/shared # SGID，保持属组统一 setfacl -d -m g:dev:rwx /data/shared # 默认授权开发组 chown -R root:devops /data/logs chmod -R 750 /data/logs

这个方案看起来是把命令写完了，但真正落地时还要注意几个点。第一，chmod -R会覆盖目录内所有文件权限，如果里面有需要单独保留权限的特殊文件，应该是先重置大目录，再单独设置那些文件，而不是一把梭。第二，setfacl -d为目录设置了默认规则，但已有文件是没被覆盖的，如果旧文件也需要同样权限，得用setfacl -R或重新复制数据。第三，我建议在改完权限后，用几个不同身份分别测试一下，比如切换到一个普通开发用户试试能否在/data/shared里新建文件。

测试命令：

sudo -u zhangsan touch /data/shared/test.txt sudo -u lisi cat /data/shared/test.txt

凡是有一步被拒绝，就逐层检查：文件权限、所属组、ACL、mask。实际工作中这种“设好了但访问不了”的情况占我排查量的七成，原因基本都落在上述几个环节里。

关于权限规划的总体经验，我有几条总结：

• 能用组解决的问题就不要给个人单独开权限，组是权限管理的主单元。
• 目录权限设计要提前留好扩展空间，临时补权限容易造成规则混乱。
• 尽量不要在运行中的服务目录里大面积递归改权限，先停服再操作，不然进程可能因为权限变更加载失败。
• 每次调整权限后一定要用ls -l和getfacl核实一遍，确认实际权限与预期一致。
• 生产环境慎用ACL，虽然灵活，但备份恢复、审计排查时很容易遗漏。

回到最开始说的“为什么你看着权限没问题但就是进不去目录”这类问题，排除过程基本逃不开这几步：看当前用户身份id、看目录权限ls -ld、看目录所有者stat、看父目录每一级的x权限。尤其是多级目录时，每一级都要有x权限才能逐层进入，缺一层就“迷宫”，这是很多新手最爱忽略的。

这套权限知识我用了差不多两年才算真正滚瓜烂熟，期间踩过的坑，比如误设SUID、ACL mask导致权限异常，都记在了上面。Linux权限管理就是这样，规则清晰，但要配合场景去体会，光背命令不理解规则，换个场景照样发懵。多建几个用户和组，把文中的案例反复演练几遍，基本就能把权限这道门彻底推开。