权限改不对先别急着 chmod 777：用 ls -l、用户组和 umask 把权限讲清楚

程序报“Permission denied”时，很多人第一反应是 chmod 777：权限一放开，程序确实能跑了，但隐患也跟着来了——任何用户都能改这个文件，敏感配置和密钥文件都可能被顺手读走或改掉。更麻烦的是，777 往往掩盖了真正的问题：到底是谁在访问这个文件、它需要的是读、写还是执行权限，改完之后没人再追究。下次换一台机器、换一个用户，同样的问题又会冒出来。先把权限讲清楚再动手，顺序不能反。

第一步是用 ls -l 把现状读出来。-rw-r–r-- 这样的十位字符，前一位是文件类型，d 是目录、- 是普通文件，后面九位每三位一组，依次是属主、属组、其他人的读（r）、写（w）、执行（x）权限。很多问题一看就明白：文件属主是 root，而跑程序的用户是普通用户，其他人那组又没有读权限，程序当然读不到。只看报错不看这一行，就只能靠猜。

第二步是确认“谁”在访问。程序以哪个用户的身份运行，决定了它落在九位权限里的哪一组：属主、属组还是其他人。用 ps 可以看到进程的运行用户，用 id 可以看到当前用户属于哪些组。常见情况是文件属组不对：文件属于旧项目组，而新同事的用户还没加进这个组，于是读不到共享文件。这时正确的做法是把用户加进对应的组，或者把文件属组改成正确的组，而不是把权限放开给所有人。

第三步是区分文件权限和目录权限。目录的 x 权限不是“执行”，而是“进入目录、访问其中文件”的许可。只给文件加了读权限，却忘了上级目录没有 x，结果还是打不开；反过来，目录给了 w 权限，就意味着可以在里面新建、删除、重命名文件，哪怕文件本身是只读的。排查时要从上往下看每一级目录的权限，缺了哪一级都会卡住。

第四步是理解 umask 这个“默认扣分项”。新建文件默认是 666、新建目录默认是 777，再减去 umask 的值，才是实际权限。umask 是 022 时，新文件就是 644、新目录就是 755，是比较稳妥的默认值；如果 umask 被改成了 000，新文件就会默认所有人可写。发现新建文件权限总是不对，先查 umask，而不是每次事后 chmod 补救。

最后动手时坚持最小权限：先定“谁需要访问”，再定“需要读、写还是执行”，最后只改必要的位。日志文件给属主写、属组读即可；Web 静态文件一般 644、目录 755；密钥和配置文件只给属主 600。改完用对应用户身份实际访问一次验证，而不是只看数字对不对。权限问题很少是孤立的数字错误，它背后往往是用户、组和目录链条上某一环没对上。先读权限、再认身份、最后才改位，权限报错才不会越放越宽。