chmod 755、chmod 644 是 Linux 运维中最常见的命令之一，也很容易被机械复制。权限给得太小，服务无法读取文件或进入目录；权限给得太大，又可能让其他用户修改脚本、配置甚至上传恶意内容。
本文从八进制、符号权限、文件与目录差异讲起，再解释 setuid、setgid 和 Sticky Bit，帮助你在执行命令前知道每一位权限的真实影响。
1. 三组权限分别属于谁
典型的权限字符串如下：
text
-rwxr-xr-x第一个字符表示文件类型，后面 9 个字符分成三组：
text
rwx r-x r-x
| | |
| | +-- others：其他用户
| +------- group：所属组
+------------ owner：所有者r、w、x 分别代表 read、write、execute；缺少权限的位置用 - 表示。
2. 为什么 rwx 能转换成 755
每组权限使用三个二进制位表示，并赋予固定权重：
| 权限 | 二进制位 | 数值 |
|---|---|---|
read (r) |
100 | 4 |
write (w) |
010 | 2 |
execute (x) |
001 | 1 |
一组中拥有的权限相加即可：
text
rwx = 4 + 2 + 1 = 7
r-x = 4 + 0 + 1 = 5
rw- = 4 + 2 + 0 = 6
r-- = 4 + 0 + 0 = 4所以：
text
rwxr-xr-x = 755
rw-r--r-- = 644
rw------- = 600输入 0755 或 0o755 时，前缀用于强调这是八进制；实际权限的三位仍是 owner、group、others。
3. 文件和目录的 r、w、x 含义不同
这是 chmod 最容易被忽略的部分。
对普通文件
r：读取文件内容；w：修改文件内容；x：将文件作为程序或脚本执行。
对目录
r：列出目录中的名称；w：在目录中创建、删除或重命名条目；x：进入目录，并访问其中已知名称的对象。
目录只有 r 没有 x 时，通常能看到名称却无法正常读取条目元数据或进入目录。目录有 x 没有 r 时，如果已经知道完整文件名且其他权限允许，仍可能访问该文件，但不能列出目录内容。
删除文件通常由父目录的 w 和 x 权限决定，不只取决于文件本身是否可写。这也是"文件设为只读却仍被删除"的常见原因。
4. 常见权限应该怎样选择
| 权限 | 常见用途 | 含义 |
|---|---|---|
644 |
普通文本、静态资源 | 所有者可读写，其他人只读 |
600 |
私钥、个人配置 | 仅所有者可读写 |
755 |
公共目录、可执行程序 | 所有者可写，所有人可读和执行/进入 |
700 |
私有目录或脚本 | 仅所有者拥有全部权限 |
664 |
组内协作文件 | 所有者和组可读写 |
775 |
组内协作目录 | 所有者和组可写，其他人只读和进入 |
1777 |
共享临时目录 | 所有人可写，但受 Sticky Bit 限制删除 |
这些是起点，不是放之四海而皆准的答案。Web 服务实际需要的权限，还取决于进程用户、所属组、父目录权限、ACL、SELinux/AppArmor 和容器挂载方式。
5. 为什么不建议随手 chmod 777
777 意味着所有用户都可以读取、修改和执行。它可能短暂掩盖"服务用户或所属组配置错误"，却把问题转换成安全风险：同机其他账号、被入侵的低权限服务或错误脚本都可能篡改文件。
更好的排查顺序是：
- 用
ps、systemd 或容器配置确认进程以哪个用户运行； - 用
ls -l、namei -l检查目标和所有父目录； - 确认 owner 与 group 是否正确，必要时使用
chown/chgrp； - 只给业务所需的最小权限；
- 若传统权限不足，再检查 ACL 和安全模块策略。
不要用递归 chmod -R 777 处理生产目录。它会同时改变文件与目录，而两者对 x 的需求不同，还可能破坏私钥、配置和可执行文件原本的保护。
6. 第四位数字：setuid、setgid 与 Sticky Bit
四位权限中的第一位用于特殊权限：
| 特殊权限 | 数值 | 典型效果 |
|---|---|---|
| setuid | 4 | 执行文件时使用文件所有者的有效身份 |
| setgid | 2 | 执行文件时使用所属组身份；目录中新文件继承目录组 |
| Sticky Bit | 1 | 共享目录中限制用户删除他人的文件 |
特殊位也可以相加。例如 6755 同时设置 setuid 和 setgid。
setuid
setuid 常见于少数需要受控提权的系统程序。给自定义二进制设置 setuid 前必须进行严格安全审计；许多系统会忽略脚本上的 setuid，以避免解释器竞态等风险。
setgid
setgid 用在协作目录时很实用：目录中新建文件会继承目录的所属组，减少团队成员各自产生不同 group 的问题。它仍需配合合适的 umask 或默认 ACL。
Sticky Bit
/tmp 常见权限是：
text
drwxrwxrwt 1777所有人都可以创建文件，但 Sticky Bit 会限制用户删除或重命名不属于自己的条目。它不是"禁止所有人删除"，目录所有者和特权用户仍有相应能力。
权限字符串中，特殊位会显示为 s、S、t 或 T。小写通常表示对应的执行位也已设置，大写表示特殊位存在但执行位未设置，需要额外检查是否符合预期。
7. 相对修改与绝对设置
八进制写法会一次设置完整权限：
bash
chmod 640 app.conf
chmod 750 deploy.sh符号写法适合只调整某一部分：
bash
chmod u+x deploy.sh # 给所有者增加执行权限
chmod g-w app.conf # 移除所属组写权限
chmod o-rwx private.key # 移除其他用户全部权限
chmod g+s shared-dir # 给协作目录设置 setgid其中 u、g、o、a 分别表示 user、group、others、all。自动化脚本中应明确期望的最终权限，避免结果依赖目标原先状态。
8. 执行前先计算和检查
不熟悉位数时，可以使用 Tool-Tic chmod 权限计算器 在八进制、rwx 字符串和权限矩阵之间同步转换，并生成 chmod 755 path/to/file 形式的命令。它支持 setuid、setgid、Sticky Bit 以及常见权限预设，并会提示 others 可写等风险。所有计算都在浏览器本地完成，工具不会访问文件系统，也不会替你执行命令。
真正执行前，仍要检查：
bash
ls -ld path/to/directory
ls -l path/to/file
stat path/to/file修改后再读取一次实际权限，不要只相信命令没有报错。若结果与预期不符，继续检查挂载参数、ACL、umask、SELinux/AppArmor 和容器内外的用户映射。
结语
理解 chmod 的关键，是把三位数字还原成 owner、group、others 的 rwx 组合，并区分这些权限对文件和目录的不同作用。面对权限故障时，先确认进程身份和路径上的每一级目录，再按最小权限原则修改；777 应是风险信号，而不是通用修复方案。