WordPress|WordPress 权限方案 WordPress权限方案

每个主机和主机的情况可能有所差异，如下只是概括性地描述，并不一定适用于所有情况。它只适用于进行“常规设置”的情况（注：比如通过“suexec”方式来进行共享主机的，详情见下方）

通常，所有文件是由您的账户（或者说是 FTP 账户）所有的，同时您的账户也具有写权限。在共享主机上，文件不应该由网页服务器本身的进程所有（有时候是www、apache或nobody用户）。
所有 WordPress 需要写的文件，都应由 WordPress 使用的用户账户所有，或由该账户所在的组所有。比如说，您有一个用于 FTP 文件传输的用户帐户，但您的服务器使用另一个单独的用户，该用户又在单独的用户组中（比如 dhapache or nobody）。如果 WordPress 以您的 FTP 账户运行，那个账户则需要拥有写权限 —— 也就是说，成为该文件的所有者，或处于拥有写权限的组中。在后面的例子中，则需要设置比默认值更高的权限（比如，应在目录上应用 775 权限，而不是 755；应在文件上应用 664 权限，而不是 644）。
对于 WordPress 来说，文件和目录的设置在大多数情况下对于所有用户都应一样，这取决于您的安装类型，以及您系统安装时的 umask 设置。
NOTE: 若您是自己安装 WordPress，您大概不需要修改文件权限。除非您遇到了权限方面的问题，或您希望进行更改。
Template:Note 2

通常，所有 WordPress 核心文件都应只能有您的用户账户（或 httpd 所用的账户）所写入。（有时候您可能使用多个 FTP 账户来管理 WordPress 文件，且所有的 FTP 账户都十分可信，比如您不在共享的主机上，那么为组设置写权限也可以。请联系主机提供商以了解详情。）然而，若您使用 mod_rewrite 固定链接等 .htaccess 功能，则您需要让 WordPress 对/.htaccess文件可写。
若您希望使用内置主题编辑器，所有文件应对组可写。在修改之前请先编辑试试，看看能否直接编辑成功。（如果是多个用户上传的 WordPress 包、插件或主题，则大概需要进行修改。若主题和插件是通过站点后台安装的，就不会有问题。在共享主机中，请确认该组中只有您信任的用户... apache 不应作为用户，也不应该拥有文件。）
有些插件需要 /wp-content/ 目录可写 —— 如果这样，插件会在安装过程中告知您。有时，可能需要您分配 775 权限。同样，在某些情况下您也可能需要令/wp-content/cache/和/wp-content/uploads/可写（若使用了多站点，则也需要/wp-content/blogs.dir/可写）。
关于插件的其它权限要求，请见插件相关文档。

/ |- index.php |- wp-admin |`- wp-admin.css |- wp-blog-header.php |- wp-comments-post.php |- wp-commentsrss2.php |- wp-config.php |- wp-content ||- cache ||- plugins ||- themes |`- uploads |- wp-cron.php |- wp-includes `- xmlrpc.php

使用 suexec 的共享主机

上方的权限设置可能不适用于使用了“suexec”来运行 PHP 的共享主机。当今很多服务提供商都开始使用这种方式了。在这种情况下，PHP 进程以 PHP 文件的所有者来运行，使配置变得更加简单、安全。

注意：suexec 方式不应用于单用户情况下，因为它们只有在多个用户存在的时候才更安全。
在这种 suexec 的配置下，正确的权限方案很好理解：

所有文件应由用户的账户拥有，而不是 httpd 所使用的账户。
组的权限设置无关紧要了，除非网页服务器进程需要进行权限检查。通常不会。
所有目录应设置为 755 或 750。
所有文件应设为 644 或 640。例外：wp-config.php 应设为 600，以防其它用户读取。
不应给任何目录设置 777 权限，上传目录也不行。由于 PHP 进程是以文件所有者的身份运行，它甚至可以写入 755 权限的目录。

使用 FTP 客户端
FTP 程序（客户端）允许你在远程主机上为文件及目录设定权限。此功能在程序菜单中一般显示为chmod或设定权限。
本文已被标记为需要加工。欢迎您踊跃编辑它，来帮助 Codex。
在 WordPress 安装中，你可能想要修改的两个文件应该是索引页，以及控制布局的CSS。这里给出修改 index.php 的方法 -其他文件的修改步骤也是如此。

看以下截图中的最后一栏 - 即显示权限的地方。看起来是不是有点让人迷惑，先不管它，注意字母的次序即可。

初始权限
右击'index.php'并选择'文件权限'
然后就会弹出一个窗口。

文章图片

修改文件权限
别管这些复选框。只要删除'Numeric value:'的内容并输入所需的数值即可 - 此例中为666，点击确定（OK）即可。

权限已被修改
现在你应该能看到权限已经被修改了。

显示隐藏文件

默认情况下，大部分FTP客户端，也包括FileZilla，都保留有隐藏文件，这些文件开头都带有一个句点(.)，这样一来就不会显示出来了。不过在某些情况下，你可能需要查看这些隐藏文件，因此你就需要对这些文件的权限进行修改。比如，你可能需要使控制固定链接的.htaccess文件可写。

要在FileZilla中显示隐藏文件的话，就要选择顶部菜单中的'查看（View）'，然后选择'显示隐藏文件'。然后屏幕中显示的文件就会刷新，之前被隐藏的文件此时就会显示出来。
让FileZilla总是显示隐藏文件 - 编辑（Edit）下，设定（Settings），远程文件列表（Remote File List），选择总是显示隐藏文件（Always show hidden files）即可。

使用命令行
如果你可以通过shell/SSH访问主机帐户的话，就可以使用chmod来修改文件权限，此方法推荐高级用户使用。在你开始使用chmod之前最好阅读一下相关教程，以确认你自己完全了解该方法。如果权限设定不正确的话，你的网站就有可能会离线。

Unix权限
Apple Chmod相关参考

完成2个步骤你就可以让wp-content目录下的所有文件可写，但在让每个文件及文件夹可写之前，你应当采取较安全的手段来修改目录。请尝试各命令，如果没用的话，请依次进行尝试，有的甚至可以让外观主题图片文件变成可写。将DIR替换为你希望进行写入操作的文件夹

chmod 746 -v DIR chmod 747 -v DIR chmod 756 -v DIR chmod 757 -v DIR chmod 764 -v DIR chmod 765 -v DIR chmod 766 -v DIR chmod 767 -v DIR

如果以上这些均不允许你进行写操作，请按次序重试一次，不过这次请将 -v替换为 -R，这将递归式地修改位于文件夹中的各文件。如果完成此操作后仍无法写入的话，就可以尝试777了。

关于Chmod

chmod是一个unix命令，表示修改文件的模式（即"change mode"）-R标记的意思是将修改应用于wp-content中的所有文件及目录。766是我们所要修改的目录具有的权限，它表示目录可被WordPress及系统中其他所有的用户读和写。最后我们有了需要修改的目录名称，wp-content。如果766无效的话，你可以尝试使用777，这将使得所有的文件及文件夹对于所有用户，组合进程可读，可写及可执行。

如果你使用了固定链接，就应当修改.htaccess 文件的权限以保证WordPress能够在你修改设定时进行更新，如新添页面，重新导向和分类时，就需要更新.htaccess文件。

打开WordPress主目录
输入chmod -v 666 .htaccess

NOTE: 就安全性方面来看，对全局可写目录进行最低限度的保护也是很好的。使用 744这一具有较低许可范围的设定做为开始，直到符合要求即止。如有必要的话才使用777，且时间不宜过久。

使用777的弊端
有关此权限的关键问题是，你的服务器是如何设置的。你用FTP或SSH登入服务器的用户名很可能不是服务器程序所使用的用于页面托管的用户名。

777 usergroupworld r+w+xr+w+xr+w+x 4+2+14+2+14+2+1= 777

Apache服务器通常为dhapache或nobody用户帐户拥有。这些帐户对服务器文件的访问时受限的。通过将你的用户帐户拥有的个人文档及文件夹设定为全局可写，那么这些文件及文件夹就确实为全局可写了。现在dhapache及nobody用户对你的用户帐户文件就具有完全的访问权了。

但同时这就使得某些人可以通过劫持你服务器上的任何进程来访问你的文件了，这还包括了在你机器上的其他用户。因此修改权限时应当慎重。至少我从来没有遇到过需要制定超过767权限的情况，因此在看到777时，自然就应当问问为何需要使用它。

最坏的结果

作为将一个目录甚至于一个文件的权限设置为777的最坏结果，恶意攻击者将可以上传文件或者修改已经存在的文件来执行代码，以获得你的博客的所有控制权，包括你的数据库和密码。

寻找替代方法

通常可以通过Wordpress插件得到特性的增强，而无须自己面对潜在的危险。可以联系插件作者或者你的主机服务商来寻求解决方法。

关于安全文件权限
.htaccess文件是被当前服务器进程所有者访问的一个文件。所以如果你摄制的权限过低，那你的服务器将无法访问该文件从而引发错误。可以通过逐步增加权限直到可以正常工作的方式来寻找最佳权限设置。

权限配置实例

下面是一个关于自定义编译php-cgi为二进制和自定义php.ini指定cgi-bin执行目录的例子。通过.htaccess文件防止用户浏览器直接访问编译器和php.ini。

默认权限 (umask 022)

644 -rw-r--r--/home/user/wp-config.php 644 -rw-r--r--/home/user/cgi-bin/.htaccess 644 -rw-r--r--/home/user/cgi-bin/php.ini 755 -rwxr-xr-x/home/user/cgi-bin/php.cgi 755 -rwxr-xr-x/home/user/cgi-bin/php5.cgi

Secured Permissions

600 -rw-r--r--/home/user/wp-config.php 604 -rw----r--/home/user/cgi-bin/.htaccess 600 -rw-------/home/user/cgi-bin/php.ini 711 -rwx--x--x/home/user/cgi-bin/php.cgi 100 ---x------/home/user/cgi-bin/php5.cgi

.htaccess权限
644 > 604 - The bit allowing the group owner of the .htaccess file read permission was removed. 644 is normally required and recommended for .htaccess files.

php.ini权限
644 > 600 - 预先允许所有的组和所有的用户都可以访问这一服务器上的php.ini文件，哪怕这样的请求来自于网站。比较棘手的是php.ini只能被php.cgi 使用，我们只需要确认php.cgi进程是否已经在访问了。php.cgi在两个文件属于同一用户的时候会执行，也就意味着只有一个用户可以访问这一文件。

php.cgi权限
755 > 711 这一文件是一个编译好的php-cgi二进制用来替换mod_php或者主机提供商默认的php目录。默认的权限是755。

php5.cgi权限
755 > 100 - 由于安装的用户就是运行php cgi进程的所有者，其他的用户或者组不需要访问，所以我们禁止了所有的除了执行的访问。这非常有趣，你可以尝试读取文件，写文件等操作，不过这都需要执行php脚本。而作为这一文件的所有者你可以随时改变它的权限。