WordPress 文件权限为什么改成 777？这样做真的安全吗？

你有没有遇到过这种情况？用 FTP 上传 WordPress 主题，FTP 里明明可以正常修改。但一进 WordPress 后台，却提示：无法编辑、无法写入。

然后上网一搜，很多教程都会告诉你：

chmod 777 -R 网站目录

执行之后，确实好了。但问题是为什么这样就好了？以及，更重要的网站真的应该这样设置吗？

Linux 文件权限

在 Linux 中，文件最基本的权限有三种：r、w、x，分别代表：

不过对于文件和目录来说，具体含义有一些区别。

这里还有一个容易产生误解的地方。

像 PHP、Python 这样的脚本，并不一定需要文件本身具备 x 权限。

例如 PHP 文件通常是交给 PHP-FPM 这样的解释器读取和执行的，只要运行它的用户能够读取文件，就可以正常处理。

Linux 文件权限还分成三组：Owner/User、Group、Other 也就是：所有者、所属组、其他用户。

我们执行：

ls -la

通常可以看到类似：

-rw-r--r-- 1 user group index.php

这里的：

rw- r-- r--

就是三组权限。

第一组是文件所有者的权限。

第二组是所属组的权限。

第三组就是其他用户的权限。

权限还可以用数字表示：

r = 4
w = 2
x = 1

所以：

6 = rw-
5 = r-x
7 = rwx

也就有了我们经常看到的：

644
755
777

综上说明，我们可以看到777 就是：

Owner   rwx
Group   rwx
Other   rwx

三组全部拥有读、写、执行权限，所以你执行：

chmod 777 -R 网站目录

之后，原本没有写权限的 Web 服务用户，也可能因为属于 Other，突然获得了写权限，WordPress 自然就可以修改文件了。

所以 777 确实能解决问题。但问题也正出在这里，你为了让 WordPress 能写文件，实际上把其他用户的权限也一起放开了，对于网站来说，这显然不是一个很好的权限管理方式。

再回到最开始的问题，你通过 FTP 上传文件时，文件通常属于 FTP 使用的那个用户，但 WordPress 在后台运行时，用的却是 Web 服务器用户。

例如：

FTP 用户：ftpuser
Web 服务：www-data

这两个并不是同一个用户。假设 FTP 上传的文件权限是：

-rw-r--r--

那么：

ftpuser     可以读写
www-data    只能读取

所以你在 FTP 里修改没有问题，但 WordPress 尝试修改时，就会发现自己没有写权限。

这也是为什么：FTP 可以改，WordPress 后台却改不了。

既然问题是 FTP 用户和 Web 服务用户不同，那么更合理的做法，是让它们通过同一个用户组共享需要的权限。例如创建一个专门的网站用户组：

w3serv

然后让 FTP 用户和 Web 服务用户都属于这个组，接下来，再给文件和目录设置合适的组权限，这样：

FTP 用户 → 写入文件

Web 服务用户 → 通过 Group 获得写权限

两边就可以正常协作。

这样做的好处是，你只开放给真正需要访问网站文件的用户，而不是简单地把 Other 的权限也全部打开。

如果只处理现有文件还不够，以后 FTP 新建文件时，也需要让这些文件自动带上合适的组权限，这时候就要调整 FTP 服务的文件创建掩码，也就是 umask，配置好之后，FTP 上传的新文件就可以自动使用正确的组权限。

这样以后就不需要 chmod ，上传一个文件执行一次，整个网站的文件权限也会更加稳定。

所以，WordPress 出现“无法写入”时，chmod 777 -R 确实是最快的解决办法，但不应该成为最终的解决方案。

真正需要解决的是：FTP 用户和 Web 服务用户之间，应该如何正确地共享网站文件权限。至于如何通过更高级的 Linux 权限机制，让不同用户之间实现更精细的权限控制，这又是另外一个话题了。