上周三凌晨两点，服务我接到运维老张的器文权限电话，说测试服务器上一个上传目录被挂马了。设置攻击者往里面塞了一个PHP文件，服务通过它执行系统命令。器文权限我连上服务器一看，设置那个目录的服务权限是 777——任何人可读可写可执行。问了一圈，器文权限是设置前端组为了调试方便临时改的，后来没人记得改回来。服务

这事不新鲜。器文权限文件夹权限出问题，设置十次里有八次是服务“临时改一下”留下的尾巴。Linux 用 rwx 三个字母管权限，器文权限对应读、设置写、执行。数字表示就是 4、2、1。你看到 755，意思是所有者能读能写能执行，同组用户和其他人只能读和执行。你看到 644，所有者读写的，其他人只读。就这么简单。

但简单的东西往往最容易出错。我见过一个项目，整个网站根目录设成 777，问为什么，答“不然图片传不上去”。其实只需要把上传目录单独设成 755 并让 PHP 进程用户拥有写权限就行。777 意味着服务器上任何一个用户、任何一个进程都能往这个目录里塞东西。如果服务器上还跑着别的应用，一个被攻破，其他全完。

目录权限和文件权限需要分开对待。目录的“执行”权限（x）决定你能不能进入这个目录，文件通常不需要执行权限。所以目录一般是 755，文件是 644。有些程序需要写入日志或缓存，那就把对应的子目录设成 775，并且把所有者改成 Web 服务的运行用户，比如 www-data 或 nginx。命令很简单：chown -R www-data:www-data /var/www/app/storage，然后 chmod -R 775 /var/www/app/storage。别偷懒对整个项目做这个操作。

还有一种情况是 umask 没设对。新创建的文件和目录默认权限由 umask 控制。默认 umask 022 时，新目录是 755，新文件是 644，这没问题。但如果 umask 是 000，新目录就是 777，新文件是 666。我在一台老旧服务器上见过 umask 被改成 000，因为某个脚本需要“完全权限”。结果上传的每个文件都成了 666，攻击者直接覆盖了配置文件。

Windows 服务器也有类似问题。IIS 里给文件夹加 Everyone 完全控制，相当于 Linux 的 777。正确做法是给 IIS_IUSRS 或应用程序池身份读写权限，其他用户只给读取。右键属性、安全、编辑，几步就能搞定，但很多人嫌麻烦直接加 Everyone。

我的习惯是每次部署完立刻跑一遍权限检查。用 find /var/www -type d -perm 777 找所有 777 的目录，再用 find /var/www -type f -perm 666 找文件。有输出就说明有问题。另外，别把权限和所有者搞混。权限是“能做什么”，所有者是“属于谁”。一个 755 的目录如果所有者是 root，而 Web 进程是 www-data，那 www-data 只能读不能写。你得把所有者改成 www-data，而不是把权限改成 777。

最后说个真实案例。某电商网站的商品图片目录被设成 777，攻击者上传了一个伪装成图片的 webshell，然后通过它读取了数据库配置文件。数据库密码是明文，整个用户表被拖走。修复只花了十分钟改权限，但数据泄露的代价远不止十分钟。权限设置不是“差不多就行”的事，它是服务器安全的第一道门。门没锁好，后面装再多防盗网也没用。