Linux权限管理实战：从rwx到ACL与sudo，彻底排查Permission denied

上周碰到一个问题，一台跑着内部工具的服务器突然报“上传目录写入失败”，应用日志里只有一行 Permission denied。我登录上去先看了磁盘空间，没问题；看了进程，没问题；最后用 ls -ld 看了一眼上传目录，才发现前天做目录整理时，新目录的属主是 root，而应用进程跑在 www-data 用户下，755 的权限让 www-data 根本没有写入资格。这种问题说大不大，但如果你只停留在“Linux 权限不就是 rwx 那三位吗”的认知层面，排查起来就会绕很多弯。

这篇文章我不打算写成一个面面俱到的教程，而是把我实际工作中和 Linux 权限相关的经验串一遍：从最基础的权限模型，到用户和用户组，到 SUID/ACL/sudo 这些进阶机制，最后是排查 Permission denied 的完整思路。适合刚接触 Linux 的新手，也同样适合那些偶尔被权限问题卡住、想系统性把这块补上的后端开发、运维同学。

1. 从一次 "Permission denied" 说起：权限模型到底在管什么

1.1 三个主体、三种操作：Linux 权限的最小单元

权限问题之所以让很多人头疼，是因为你面对的永远是一串看似简单的字符，但它背后至少叠了两层逻辑：谁在访问，以及要做什么。

Linux 传统的 POSIX 权限模型把访问者分成三类：

• 属主（u，user）：文件或目录的所有者，通常就是创建它的用户。
• 属组（g，group）：文件所属的用户组，组内所有成员都会受到这一档权限的约束。
• 其他人（o，other）：上面两种之外的所有用户。

对每种身份，又定义了三种操作：

• 读（r，read）：值为 4。对文件来说是查看内容；对目录来说是列出目录里的文件名。
• 写（w，write）：值为 2。对文件来说是修改内容；对目录来说是在里面创建、删除、重命名文件。
• 执行（x，execute）：值为 1。对文件来说是运行它（脚本、二进制程序）；对目录来说是“穿过”它，也就是 cd 进入这个目录或者访问目录里的文件。

所以你会看到 rwxr-xr-- 这样的字符串：前三位是属主权限，中间三位是属组权限，后三位是其他人权限。rwxr-xr-- 翻译过来就是属主可读可写可执行，属组和其他人只能读和执行，不能写。

数字模式（比如 644、755、777）就是这三组权的二进制压缩。rwx 对应 4+2+1=7，r-x 对应 4+0+1=5，r-- 对应 4。所以 rwxr-xr-- 等于 754。这个转换关系我建议你彻底记住，因为后面无论用 chmod 还是写脚本，都会频繁用到，算错了真的会出事故。

1.2 目录权限与文件权限：经常被忽视的差异

我见过不少人对文件权限很熟，但一到目录就翻车，因为目录的 rwx 和文件的 rwx 看起来一样，含义却完全不同。

• 目录的 r 权限：只允许你列出这个目录里有哪些文件名。注意是“列出文件名”，但并不能获取文件的属性信息，也不能访问文件内容。
• 目录的 w 权限：允许你在目录里创建、删除、重命名文件。这个操作和文件本身的权限没有关系，只管目录权限。
• 目录的 x 权限：允许你进入目录，并访问里面文件的具体属性。没有 x 权限，即使你有 r 权限，ls -l 也会报权限错误，因为拿不到每个文件的 metadata。

这里有一个特别容易踩的坑：删除一个文件，你需要的不是对这个文件的写权限，而是对它所在目录的写权限。 所以一个用户可能对某个文件一点权限都没有，但只要他对父目录有 w+x 权限，他就能把这个文件删掉。这就是为什么 /tmp 这种共享目录必须设置 sticky bit（后面会讲），否则任何人都能删掉别人的临时文件。

我建议你把目录权限的这三条规则抄在笔记里，遇到“我能看到文件名但打不开”“我能删别人的文件”这类怪问题时，回来对照一下，基本能定位。

1.3 属主和属组为什么比权限位更重要

很多人排查权限问题只看权限位是不是 755 或者 644，往往忽略了一个更前提的问题：这个文件到底属于谁？

权限位的每一档（u/g/o）都要跟具体的属主搭配才有意义。一个文件是 root:root 拥有、755 权限，和一个文件是 www-data:www-data 拥有、755 权限，对运行中的 www-data 进程来说完全是两种结局——前者只能读不能写，后者能写。

所以遇到权限问题，我的第一反应永远是执行 ls -l 看前三列：文件类型、属主、属组，而不是先盯着权限数字看。身份错了，权限位再宽松也没有用。

2. chmod/chown/umask 的实战细节：别只会 777

2.1 ls -l 输出逐字段拆解

在动手改权限之前，你要确保自己能读懂 ls -l 输出的每一个字段。拿一条真实输出举例：

code复制-rw-r--r-- 1 root root 2048 Feb 20 10:32 app.conf
drwxr-xr-x 2 dev  dev  4096 Feb 20 10:33 logs/

第一列总共 10 个字符：第 1 个是文件类型，- 表示普通文件，d 表示目录，l 表示符号链接，c 是字符设备，b 是块设备。后面 9 位就是刚才说的 u/g/o 三组权限。如果这 9 位后面出现一个 . 或 +，那就要注意了：. 通常表示 SELinux 开启且文件有安全上下文标记，+ 表示文件设置了 ACL 扩展权限。这俩都是“异常信号”，看到就要多留个心眼。

第 2 列是硬链接数，对普通文件来说通常为 1，对目录来说表示子目录数加 2。第 3、4 列就是属主和属组。第 5 列是文件大小（字节）。后面是修改时间和文件名。

这套字段看着基础，但踩过的坑都在细节里。比如符号链接的权限位永远是 lrwxrwxrwx，真正生效的权限是链接指向的文件的权限，所以别对链接本身做 chmod，改了也是白改。

2.2 chmod 符号模式和数字模式的换算

chmod 有两种写法，我建议两种都掌握，因为不同场景用起来效率差很多。

符号模式适合精确改某一位，可读性强：

bash复制chmod u+x script.sh        # 给属主加执行权限
chmod g-w,o-rwx file       # 去掉属组写权限、去掉其他人的所有权限
chmod a+r file             # 所有人加读权限

数字模式适合一次把权限设为明确目标：

bash复制chmod 644 app.conf         # 属主读写，组和其他人只读
chmod 755 deploy.sh        # 属主全部权限，组和其他人读+执行
chmod 750 private_dir      # 属主全部权限，组读+执行，其他人无权限

关于递归操作 chmod -R，我只有一句忠告：用之前想清楚，用之后立刻验证。 chmod -R 777 /var/www 这种命令会让目录下所有文件全部开放可写，而很多时候你只是想让目录可遍历、文件可读，根本不需要写权限。正确做法是先分清哪些是目录、哪些是文件，再分别处理：

bash复制find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;

2.3 chown/chgrp 改属主时的连带问题

修改属主用 chown，修改属组用 chgrp，也可以直接用 chown 同时改两者：

bash复制chown www-data:www-data /var/www/html/ -R
chown dev:dev app.conf        # 改属主为 dev，属组为 dev
chgrp admins /shared -R       # 只改属组

这里有几个我踩过的坑：

• chown -R 之前，先确认你当前目录路径是对的。很多人从网上复制命令，没注意当前所在目录，一条 chown -R 下去把整个目录树的属主全改了，可能连系统文件都被波及。
• 修改属主只有 root 或对该文件有属主身份的用户才能做。普通用户不能把自己的文件 chown 给别人，这是 Linux 防止你把危险文件“送”给特权用户的一种机制。
• chown user:group 里的 group 可以省略，比如 chown www-data: 只改属主不动属组。

另一个常见误配置是：有人图省事，把整个应用目录 chown -R 成当前登录用户，然后生产环境里进程跑在另一个用户下，结果权限又不够了。正确的思路是：先确定运行进程的用户是谁，再决定属主应该设给谁。

2.4 umask：为什么新建文件默认是 644

很多新手会好奇：为什么我 touch 出来的文件默认是 644，而不是 666？为什么 mkdir 出来的目录默认是 755，而不是 777？答案就是 umask。

umask 是“权限掩码”，它的作用是在默认全权限的基础上减掉一部分权限。系统对文件的全量默认权限是 666（因为文件默认不应该给执行位），对目录的全量默认权限是 777。umask 里出现的位，最终权限里就不会有。

常见的 umask 022：

• 新建文件：666 - 022 = 644，即属主读写，组和其他人只读。
• 新建目录：777 - 022 = 755，即属主全部权限，组和其他人读+执行。

这里要注意，真正的实现是 666 & ~022，也就是用掩码取反后做“按位与”，所以当 umask 设成 021 时，文件结果不是 666-021=645，而是把 write 位中 mask 包含的位去掉。日常中你只需要记住 022 和 002 这两种最常用：

• umask 022：单人开发机、服务器默认值，安全。
• umask 002：多人协作的开发机，组内成员都能写新文件。

查看当前 umask 直接执行 umask，临时修改也直接执行 umask 002。要永久生效，写到 /etc/profile 或 ~/.bashrc。如果你发现新建的文件权限总不对，先去检查 umask，十有八九问题出在这里。

3. 用户、用户组与权限组：账户体系是权限的地基

3.1 /etc/passwd、/etc/shadow、/etc/group 三兄弟

权限永远围绕“用户”和“组”展开，而 Linux 里这两者的信息就存在三个文件里。虽然现在主流做法是尽量用命令去管理，但手工排查时你早晚得看这三个文件：

/etc/passwd 存的是用户基本信息，每一行七个字段，冒号分隔：

code复制dev:x:1000:1000:Developer:/home/dev:/bin/bash
内核用户态工具: 格式为 用户名:密码占位符:UID:GID:描述:家目录:登录Shell

注意这里第二个字段是 x，真实密码早就挪到了 /etc/shadow，普通用户对 shadow 文件没有读权限，所以看到的永远是个 x。

/etc/shadow 存密码哈希和密码策略，只有 root 能读。里面字段包括最后修改时间、最短/最长有效期、警告天数等。忘记密码时用 passwd 命令改，不要直接去改这个文件。

/etc/group 存用户组信息：

code复制dev:x:1000:alice,bob
内核用户态工具: 格式为 组名:密码占位符:GID:附加组成员列表

对权限来说，UID/GID 才是内核真正识别的身份。用户名只是给人看的字符串。所以当你看到一个进程以某个 UID 运行时，如果系统里没有对应的用户名，它就显示成一个数字。这就是为什么很多容器场景下，你看到容器内文件属主是一串数字。

3.2 useradd/usermod/userdel 实操

管理用户我基本只用三个命令：useradd、usermod、userdel。先看创建用户：

bash复制useradd -m -s /bin/bash dev
passwd dev

-m 表示自动创建家目录 /home/dev，-s /bin/bash 指定登录 shell。不带 -m 的新用户默认没有家目录，很多新手创建完用户后登录进去发现 cd ~ 都报错，就是这个原因。

如果还希望用户一创建就属于某个附加组，可以加 -G：

bash复制useradd -m -s /bin/bash -G www-data,dev dev

创建后会生成 UID/GID，而且通常从 1000 开始递增（普通用户范围）。系统用户（UID 小于 1000）则用 -r 创建，这类用户没有家目录、不能登录，专门用来跑服务。

修改用户用 usermod，这里有个值得记住的细节：加附加组一定要带 -aG，不带 -a 会把用户从原来所有附加组里踢出去。 我见过不止一次，有人想给用户加 docker 组，执行了 usermod -G docker user，结果用户瞬间丢掉了其他所有组的权限，把系统搞出一堆问题。

bash复制usermod -aG docker dev     # 追加附加组，推荐
usermod -G docker dev      # 覆盖附加组，慎用

删除用户用 userdel，想连家目录一起删掉加 -r：

bash复制userdel -r dev

如果你用 userdel 没有加 -r，它的家目录和邮件池会残留，时间久了会留下一堆无人认领的文件，后续排查时也是干扰项。

3.3 主组与附加组：一个用户到底属于几个组

Linux 用户和组的关系是“一个主组、多个附加组”。用户创建时默认会有一个同名主组，useradd 时也可以通过 -g 指定：

bash复制useradd -m -s /bin/bash -g staff -G docker dev

查看用户的组身份，最直接的是 id 命令：

bash复制id dev
# uid=1000(dev) gid=1000(dev) groups=1000(dev),4(adm),27(sudo),999(docker)

第一个 gid 是主组，groups= 后面是所有附加组。很多权限问题就出在主组不对上：比如共享目录的属主是正确的，属组设置成了 staff，但你登录用户的主组是 dev，附加组又没加 staff，那 staff 这一档权限永远轮不到你头上。

我遇到过这样一个案例：一个团队在服务器上共享一个项目目录，目录权限是 775，属组是 project，按理说组内成员都能写。但有位同事就是写不进去，查了半天才发现他账号创建时主组是 developer，附加组里没有 project，而 3755 这种目录权限的“组”档对他根本不生效。把他加进 project 组并重新登录后问题立刻解决。记住：用户加入新组后，需要重新登录一次（或者重新获取会话），组权限才会在会话里生效。

4. 特殊权限、ACL 与 sudo：普通 rwx 不够用时的三把钥匙

4.1 SUID、SGID、Sticky Bit 机制与风险

当普通 rwx 满足不了复杂场景时，Linux 还有三个特殊权限位，很多人听过但没真正理解。

SUID（Set User ID）：只对可执行文件有意义，表现为属主权限位的 x 变成 s（小写表示同时有执行权限，大写 S 表示没有执行权限）。它解决的问题是：普通用户执行某个程序时，临时让这个程序以属主的身份运行。最典型的例子是 passwd：

bash复制ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ...

普通用户执行 passwd 修改自己的密码时，需要写 /etc/shadow，但这个文件只有 root 能读写。没有 SUID，普通用户根本改不了密码。SUID 让这个程序在执行瞬间获得了 root 的权限，从而完成密码写入。设置方式是 chmod u+s 程序，数字表示法是 chmod 4755 程序。

SUID 同时也是 Linux 下最常见的提权攻击面：如果一个 root 属主的程序带有 SUID，且它有漏洞，普通用户就可能借机拿到 root shell。所以安全审计里有一个必查项：

bash复制find / -perm -4000 -type f 2>/dev/null

找出所有带 SUID 的文件，看看有没有异常项。

SGID（Set Group ID）：对可执行文件，效果和 SUID 类似，只是继承的是属组身份；对目录，则有一个非常有用的特性：在这个目录下新建的文件，属组自动继承目录的属组，而不是创建者的主组。 这对共享目录来说简直是杀手级功能。设置方式是 chmod g+s 目录，数字表示法是 chmod 2775 目录。

Sticky Bit：通常只对目录设置，效果是：在带 sticky bit 的目录里，只有文件属主、目录属主或 root 才能删除文件，其他用户即使对目录有写权限也删不了。 最典型的就是 /tmp：

bash复制ls -ld /tmp
drwxrwxrwt 20 root root ...

o 位的 t 就是 sticky bit。共享目录如果不加 sticky bit，任何有写权限的人都能顺手把你放进去的文件删掉，这太危险了。设置方式是 chmod +t 目录，数字表示法是 chmod 1777 目录。

4.2 ACL：不想重新发明用户组时就用它

传统权限模型最大的限制是：每个文件只能设置一个属主、一个属组，其他人都归入“其他人”。假如你有一个共享目录，要给 Alice 读权限、给 Bob 写权限、给整个开发组执行权限，用传统权限只能干瞪眼。ACL（Access Control List）就是解决这个问题的：它可以为任意用户或组单独设置对某个文件/目录的权限。

bash复制setfacl -m u:alice:rwx /shared/project     # 给 alice 设置 rwx
setfacl -m g:dev:rx   /shared/project      # 给 dev 组设置 rx
setfacl -x g:dev      /shared/project      # 删除 dev 组的 ACL 项

查看 ACL 用 getfacl：

bash复制getfacl /shared/project

设置了 ACL 之后，ls -l 的权限位后面会出现一个 + 号，这是识别 ACL 最快速的信号。ACL 的机制说到底是给同一个文件维护了多组权限项，当用户访问文件时，内核会按照某种优先级匹配最合适的一项，不匹配就落到传统 u/g/o 的框架里。

在多人协作的服务器上，ACL 实际上比组更灵活，因为它不需要专门为某一个用户新建一个组。但要注意：ACL 增加了排查复杂度，一旦文件上叠加了 ACL，你用 ls -l 看到的那个权限位已经不是全貌了。我先用 getfacl 看清楚全貌，再动手改。

4.3 sudo：授权而非简单切换身份

sudo 不是“切到 root 再执行命令”这么简单。它本质上是一个细粒度的授权系统：你可以规定某个用户能执行哪些命令、以什么身份执行、要不要输密码。

配置文件是 /etc/sudoers，我强烈建议永远用 visudo 命令来编辑，而不是直接改文件，因为 visudo 在保存时会帮你做语法检查，写错了还能保命，否则整个 sudo 都会坏掉。

常用的配置行：

code复制dev ALL=(ALL:ALL) ALL

这行表示用户 dev 可以在任何主机上以任何用户身份执行任何命令，其实就是给了一个高级权限。更精细的例子：

code复制dev ALL=(root) /usr/bin/systemctl restart nginx

这行表示 dev 只能以 root 身份执行重启 nginx 这一个命令。sudo -l 可以查看当前用户有哪些 sudo 权力。

关于免密，可以在配置里加 NOPASSWD:：

code复制dev ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

这个在 CI/CD 场景很常用，但要注意，“免密”意味着只要有人拿到了 dev 的会话，就能直接触达这些命令，所以免密范围越小越好。

我不建议日常使用 su root 直接切到 root 或者直接把 root 密码告诉所有同事。用 sudo 的好处是：操作有审计记录、权限可以细到单条命令、临时授权也方便。我在团队里给的约定是：能用普通用户的 sudo 解决，就不碰 root 登录。

4.4 多用户服务器权限设计实测

把前面这些机制串起来，我以一台多人共用的 Web 服务器为例，讲一个我实际采用过的权限设计方案。

假设有开发组 dev，部署用户 www-data，需要保证 /var/www/html 目录下生成的缓存文件既能让 www-data 读写，也能让 dev 组的成员手动维护。

第一步，把目录属组设成 dev，并设置 SGID：

bash复制chown root:dev /var/www/html
chmod 2775 /var/www/html

这样 www-data 如果在目录里新建文件，文件的属组也会自动变成 dev，而不是 www-data，组内成员都能管理。

第二步，给 www-data 设置单独的 ACL 权限，因为它不属于 dev 组：

bash复制setfacl -m u:www-data:rwx /var/www/html

这样目录权限结构就变成了：属主 root 有完整权限，dev 组有读+执行+继承的组权限，www-data 通过 ACL 获得完整权限。没有一个人是“其他人”，也就不存在权限缺口或权限过大的问题。

第三步，把特殊目录单独扭紧。比如缓存目录 cache 由于业务需要允许写入，但我不希望有人能删别人的文件，于是设置 sticky bit：

bash复制setfacl -m u:www-data:rwx /var/www/html/cache
chmod +t /var/www/html/cache

这样整套方案既灵活又把风险压到最低，而且整个过程没有动过 777 这类大权。我强烈建议在你自己的服务器上按这个思路演练一遍，体会一下“用属组和特殊位组合代替 777”的思维方式。

5. Permission denied 的完整排查链路与修复方案

5.1 五层排查法：从命令输出定位根因

遇到 Permission denied，不要病急乱投医地换 777。我按优先级给出一套排查链路：

第一层：确认当前身份。

bash复制id

确认你登录的用户和所属组，确认当前进程运行的用户。很多时候你以为自己是 root，实际是用普通用户登录的；你以为服务是 www-data 在跑，实际是 root 或别的用户。

第二层：确认目标和中间路径的权限。

bash复制ls -ld /var/www/html
ls -l /var/www/html/index.php

注意一定是 ls -ld（列出目录本身的权限），而不是 ls -l（列出目录内容，只显示内容的权限）。也别忘了检查路径上的每一层目录，比如 /var、/var/www、/var/www/html，任何一层缺少 x 权限，都会导致最终无法访问目标文件。

第三层：检查有没有 ACL 影响。

bash复制getfacl /var/www/html

如果 ls -l 权限位后面有 + 号，别犹豫，直接看 ACL。ACL 项的优先级比传统组的权限优先级高，不看它很容易误判。

第四层：检查挂载选项和文件系统状态。

bash复制mount | grep /var
df -h /var

某些挂载选项如 noexec、nodev、nosuid 会主动阻止某些操作。比如磁盘以 noexec 挂载，即使文件有 x 权限，你也执行不了。另外只读挂载或者磁盘满也会表现为“写不进去”，这种和权限无关，但表象很像。

第五层：SELinux 或 AppArmor。

bash复制getenforce

如果是 Enforcing，就要看看是不是安全上下文限制导致的问题。RHEL 系的机器上，SELinux 是 Permission denied 的头号隐藏原因，尤其最常见的场景是 Nginx 代理、httpd 访问 /home 路径、自定义目录迁移之后，restorecon -Rv 往往能救一命。

5.2 用 namei 追踪路径中间目录权限

ls -ld 一次只能看一层，如果想一口气看全路径的每一层权限，可以用 namei：

bash复制namei -l /var/www/html/static/app.js

输出会列出路径中每一层的属主、属组和权限。这个命令冷门，但排查“中间某层目录缺权限”这类问题极其高效。我曾经靠它三秒定位到问题出在 /home/ 那层，而不是业务目录本身。

5.3 Docker 相关权限错误怎么处理

docker 相关的权限问题是热搜里的常客，也是我在新环境里经常遇到的一类报错，典型现象是：

bash复制docker ps
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

这个错误本质上就是当前用户对 Docker 的 socket 文件没有访问权限。常见处理是把用户加进 docker 组：

bash复制sudo usermod -aG docker $USER
newgrp docker

注意，加完组之后当前会话并不会立即生效，要么执行 newgrp docker 重新加载组身份，要么退出重新登录，否则还是会报同样的错。另外要清楚，把用户加进 docker 组等于授予了这个用户比较高的系统控制权（因为 docker 本质上能映射到 root 操作），所以别在共享机器上随手把所有人都加进去。

还有一类容器内的权限问题：容器里进程以 root 运行，把文件挂载到宿主机后文件属主变成了 root，宿主机普通用户无法清理。这在 Docker 场景很常见。一个思路是指定容器运行用户，比如 docker run -u $(id -u):$(id -g)，让容器进程以宿主机当前用户的 UID/GID 运行，生成的挂载文件权限就不会错位。另一个思路是在宿主机上用 chown -R 修正文件属主，但要注意先确认挂载目录的路径，别把整个数据目录的属主弄乱。

5.4 文件权限修复：回到基线而非盲目补齐

权限出问题后，正确的处理流程是：先备份原来的属主属组和权限位，再修改，改完验证，再恢复业务。

我习惯先用一条命令记录原始信息：

bash复制ls -lR /var/www/html > /tmp/perm_before.txt

然后按“目录 755、普通文件 644、可执行脚本 755”的基线来修复：

bash复制find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

如果这个目录还有上传功能，那上传目录要单独把写权限放出来，比如目录 775、属组设置为运行用户所在组。不要为了“省事”把整个站点改成 777，这样后患无穷。

修复属主时，同样要分清运行身份：

bash复制chown -R www-data:www-data /var/www/html

如果这台机器上多个用户都可能要改文件，就用之前说的 SGID + 属组方案，而不是直接给任何人开写权限。

修复完顺手跑一遍应用的关键路径，把上传、缓存清理、页面访问都试一遍。尤其注意：改完权限后，进程已经处于运行状态，某些情况下需要重启服务才会重新读取文件，或者用户需要重新登录才能让新组的权限生效。这些环节容易被忽略，导致你明明改对了却还是报错。

5.5 几类常见 permission denied 的快速对照

这张表不是标准答案，但它覆盖了我在实际排查中遇到频率最高的几类问题。遇到权限问题先把场景对应上，能少走很多弯路。

最后再分享一点个人经验。我在处理权限问题时会先问自己三个问题：运行进程的用户是谁？目标文件的属主属组是谁？目标和父目录的权限位到底给了谁？这三个问题一旦答清楚，绝大多数权限问题已经定位了八成。剩下的两成，再去怀疑 ACL、特殊权限位、SELinux 和挂载选项，按顺序排查就好。

还有个习惯建议你养成：给文件或目录做重要权限变更之前，先记录原始状态，再用最小权限原则去改——能加组就不加“其他人”权限，能用 ACL 就不开 777。权限这种东西，给出去容易，收回来难。