内容摘要：一台服务器上跑着文件共享服务，某个目录的权限设置成了 777。运维觉得省事，开发觉得方便，直到某天发现目录里多了一个从没见过的可执行文件。这种事不稀奇，SMB、NFS、FTP 共享目录配成全员可写，几

一台服务器上跑着文件共享服务，共享某个目录的目录权限设置成了 777。运维觉得省事，存写开发觉得方便，入权直到某天发现目录里多了一个从没见过的共享可执行文件。这种事不稀奇，目录SMB、存写NFS、入权FTP 共享目录配成全员可写，共享几乎是目录最常见的安全疏漏之一。

共享目录的存写写入权限本身不是问题。团队协作需要有人往里放文件，入权问题出在"谁都能写"和"谁都能以什么身份写"这两件事被混为一谈。共享Windows 共享里给 Everyone 勾上"完全控制"，目录Linux 上 chmod 777，存写看起来只是图个方便，实际上等于把目录变成了一个任何人都能投放内容的公共信箱。

我见过一个典型场景。某公司内网的文件服务器，共享目录用来交换部门间的报表。权限是 Everyone 读写，因为"反正只有内网能访问"。攻击者拿下一台普通员工的机器后，直接往共享目录里写了一个带宏的 Excel 文件，文件名模仿正常的月度报表格式。三天后，财务部有人打开了它。横向移动就这么完成了，不需要任何漏洞利用。

写权限带来的风险不只是投毒。如果共享目录同时挂载到了多台机器上，写入的内容可能被其他服务自动处理。比如一个监控系统定时扫描共享目录里的脚本并执行，或者一个构建服务器把共享目录当作制品仓库。攻击者往里面塞一个同名文件，覆盖掉正常脚本，下一次调度就是一次远程代码执行。

NFS 的情况更微妙。no_root_squash 配上可写共享，客户端上的 root 用户可以直接在共享目录里创建 SUID 文件。如果这个目录恰好被导出到了另一台机器，提权路径就打通了。很多人配 NFS 时只想着"让开发能写代码"，没想过 root squash 这个选项意味着什么。

那怎么判断一个共享目录的写权限是否危险？看三点。谁能写——是特定用户组还是所有人。写完的东西会被谁消费——有没有自动化进程会读取或执行这些文件。写进去之后能不能被验证——有没有完整性校验或审计日志。三个问题里有两个答不上来，这个共享目录就不该开放写入。

收紧权限的操作并不复杂。Windows 共享把 Everyone 换成具体的 AD 组，Linux 上用 chmod 775 配合组管理，NFS 导出加 root_squash 和 all_squash。真正难的是改变"先开了再说"的习惯。共享目录的写入权限一旦放开，就像在办公室里放了一个没有锁的意见箱——你永远不知道下一个投进去的是什么。

还有个容易被忽略的点：写权限和读权限经常被一起授予，但它们的风险等级完全不同。只读共享泄露的是信息，可写共享引入的是执行路径。审计共享目录时，可写的那些应该优先看，尤其是同时被其他服务引用的。

回到开头那台服务器。后来查清楚了，那个可执行文件是某个开发人员调试时随手放的，忘了删。但这次是善意的，下次未必。