Linux 文件权限：三位数字背后的含义与常见坑

三组身份 × 三个位

每个文件都绑定属主（user）、属组（group）、其他人（others）三组身份，每组分读 r / 写 w / 执行 x三个位。ls -l 里的 -rw-r--r-- 就是这三组的组合：属主可读写，属组与其他人只读。

数字表示法

数字是三组权限的和：r=4、w=2、x=1，例如 7 = 4+2+1（读写执行），6 = 4+2（读写）。

目录的执行位很特殊

• r：能否列出目录里有什么（ls）；
• w：能否在目录里新建或删除文件；
• x：能否进入目录并访问其中的文件。没有 x，即使有 r 也只能看到文件名而读不到内容；
• 删除一个文件取决于所在目录的 w 位，而不是文件自身的权限。

常用命令

chmod 600 id_ed25519           # 私钥只允许本人读写
chmod +x deploy.sh             # 追加执行位
chmod -R u+rwX,go-w /srv/app   # 递归：属主读写，去掉他人写权限
chown -R app:app /srv/app      # 修改属主与属组
umask 022                      # 新建文件默认 644、目录 755

注意 chmod -R 中的大写 X：它只给目录（以及已有执行位的文件）加执行位，避免把普通文件全部变成「可执行」。

五个常见坑

1. 用 777 解决权限报错：掩盖了真正的原因（属主不对或目录权限不足），同时把安全洞开到最大；
2. 递归 chmod 破坏执行位：把 644 递归到二进制目录会导致程序无法运行；
3. 私钥权限过宽：SSH 会直接拒绝使用，必须是 600；
4. 忽略 umask：进程默认 umask 不同会导致新建文件权限不一致，容器里尤其常见；
5. 以为 root 也受权限限制：root 绕过常规权限检查，测试时要用普通用户验证。

实战案例：三个权限事故

1. “改了 chmod 还是访问不了”：路径上某一级目录缺少执行位（x），无法进入。修复：逐级用 ls -ld 检查，目录至少要 x。
2. “服务部署后读不到配置”：属主/属组不对，或 umask 导致权限不一致。修复：统一 chown 与 umask，别用 777 掩盖问题。
3. “删不掉别人的文件”：删除看的是父目录的写权限（含粘滞位），不是文件本身。修复：检查父目录权限与 /tmp 这类粘滞位目录。

常见问题

为什么文件删不掉？检查父目录是否有写权限，以及是否有 immutable 属性。为什么改了权限仍不能访问？逐级检查路径上每个目录是否有 x 位。共享目录怎么协作？用共同属组 + 目录的 setgid 位，让新建文件自动继承目录属组。

权限排查的实用顺序

遇到“权限不足”时，按下面的顺序排查可以避免反复猜测。

1. 先分清是谁在访问：确认进程运行的用户与所属组，而不是只看登录用户。服务通常以专用账号运行，与你的登录身份不同。
2. 逐级检查路径：访问文件需要路径上每一级目录都有执行权限，缺少中间某一级的执行权限会直接失败，而报错往往只提示最终文件。
3. 区分读写执行：读文件需要文件的读权限，写文件需要写权限，而进入目录需要目录的执行权限。把“目录需要读权限”当成常识是常见误解。
4. 注意掩码影响：新建文件的默认权限受掩码影响，权限看起来“莫名不对”通常源于掩码配置而非文件本身。
5. 检查扩展属性与访问控制列表：基础权限满足仍被拒绝时，应查看是否存在访问控制列表或安全模块策略，它们会覆盖基础权限。

修复时应优先使用最小必要授权，而不是直接放宽到所有人都可访问。临时用宽权限解决问题，往往会长期留在生产环境里，成为难以察觉的隐患。