Linux 文件权限全攻略：深入掌握 chmod、umask 与 ACL 精细化控制实战

52JinY 助手

最近在帮一个朋友排查线上服务器问题，发现他们整个团队对 Linux 文件权限这块的理解都很模糊，出了事才来翻日志、改权限。趁这个机会，我把自己这几年踩过的坑和总结的经验整理一下，给大家说道说道。

先从最基础的 chmod 说起。很多人学会了 chmod 777 就觉得万事大吉，哪个目录访问报错了，直接一个 777 扔上去，省事是省事，但这是在把安全门直接拆掉。正确的做法是搞清楚"属主、属组、其他人"这三层关系，用 chmod 755 给目录、chmod 644 给普通文件，这是最基本的安全姿势。如果你要让某个用户能执行脚本，就精确地加 x 权限，而不是无脑开放所有位。数字模式和符号模式我都用，数字模式快，符号模式在只改某一位的时候反而更不容易出错，比如 chmod u+x 比重新算一个三位数要直观得多。

再来说 umask，这个东西很多运维同学几乎忘了它的存在，直到新建的文件权限和预期不一样才来找原因。umask 是创建文件时的"默认遮罩"，系统对新文件的默认最大权限是 666，对目录是 777，然后减去 umask 的值。常见的 umask 022 就会让文件默认变成 644、目录变成 755。如果你在某些自动化脚本里新建了配置文件，结果发现其他用户也能读到敏感内容，八成就是 umask 没设好。在生产环境里，我一般建议把 Web 应用进程的 umask 设成 027，让"其他人"连读权限都没有，这样哪怕目录结构暴露了，文件内容也不会随便泄漏。

但 chmod 和 umask 都有一个硬伤：它只能处理"属主、属组、其他人"这三个身份，现实中往往要精细得多。比如一个目录，A 用户要读写，B 用户只能读，C 用户完全不能碰，用传统权限根本表达不了这种需求，这时候就必须上 ACL 了。setfacl 是操作 ACL 的核心命令，用法也不复杂，比如 setfacl -m u:bob:r-- /data/project 就是单独给 bob 用户设置只读权限，完全不影响原来的属主和属组。配合 getfacl 来查看当前设置，整个流程很清晰。

有一个细节我吃过亏，就是 ACL 的继承问题。如果你只给目录设了 ACL，新建在里面的文件并不会自动继承，需要用 default ACL 才行。命令是 setfacl -d -m u:bob:r-- /data/project，加了 -d 参数之后，之后在这个目录下创建的文件和子目录才会继承这条规则。这个点很多教程写得不清楚，导致很多人设完之后发现新文件还是没权限，来来回回折腾半天。

另外提醒一下，ACL 要生效，文件系统挂载的时候必须有 acl 选项，大多数现代发行版的 ext4 和 xfs 默认已经开启，但如果是一些老系统或者特殊挂载配置，记得检查一下 /etc/fstab。还有就是 ls -l 看到权限位后面有个加号"+"，那就说明这个文件已经有 ACL 条目了，别忽视这个小细节。

说到底，文件权限管理考验的是你对系统安全边界的理解，不是记命令参数。最小权限原则是核心，能给 644 就不要给 755，能用 ACL 精确控制就不要无脑开组权限。线上服务器不是开发机，权限这事宁可麻烦一点，也别图省事留下隐患。