WordPress的权限方案
通常，所有文件应由您的Web服务器上的用户（ftp）帐户拥有，并且应该可由该帐户写入。在共享主机上，文件永远不应归Web服务器进程本身所有（有时这是www，或apache，或nobody用户）。
对于大多数用户，WordPress的文件和文件夹权限应该相同，具体取决于您在安装时执行的安装类型和系统环境的umask设置。
注意： 如果您自己安装了WordPress，则可能需要修改文件权限。某些文件和目录应该使用更严格的权限“强化”，特别是wp-config.php文件。该文件最初是使用644权限创建的，如此保留是危险的。
通常，所有核心WordPress文件只能由您的用户帐户（或httpd帐户，如果不同）写入。（有时候，多个ftp帐户用于管理安装，如果所有ftp用户都是已知且受信任的，即不是共享主机，那么分配可写组可能是合适的。请向服务器管理员咨询更多信息。）但是，如果您使用mod_rewrite永久链接或其他.htaccess功能，您应该确保WordPress也可以写入您的/.htaccess文件。
如果要使用内置主题编辑器，则所有文件都需要是组可写的。在修改文件权限之前尝试使用它，它应该工作。（如果不同的用户上传了WordPress包和插件或主题，则可能会出现这种情况。这对于通过管理员安装的插件和主题不会有问题。当使用不同的ftp用户上传文件时，需要使用可写组。在共享主机上，确保该组对您信任的用户是独占的... apache用户不应该在组中，不应该拥有文件。）
某些插件需要使/ wp-content /文件夹可写，但在这种情况下，它们会在安装过程中通知您。在某些情况下，这可能需要分配755权限。/wp-content/cache/也许是这样的/wp-content/uploads/（如果你使用的是MultiSite，你可能还需要这样做/wp-content/blogs.dir/）
/ wp-content /下的其他目录应该由任何插件/主题需要它们来记录。权限会有所不同。
| - index.php | - wp-admin | ` - wp-admin.css | - wp-blog-header.php | - wp-comments-post.php | - wp-commentsrss2.php | - wp-config.php | - wp-content | | - 缓存 | | - 插件 | | - 主题 | ` - uploads | - wp-cron.php | - wp-includes` - xmlrpc.php
与suexec共享主机
以上可能不适用于使用“suexec”方法运行PHP二进制文件的共享主机系统。这是许多Web主机使用的流行方法。对于这些系统，php进程作为php文件本身的所有者运行，允许更简单的配置和更安全的环境，用于共享主机的特定情况。
注意：suexec方法永远不应该用于单站点服务器配置，它们仅对于共享主机的特定情况更安全。
在这样的suexec配置中，正确的权限方案很容易理解。
- 所有文件应归实际用户的帐户所有，而不是用于httpd进程的用户帐户。
- 除非对Web服务器进程权限检查有特定的组要求，否则组所有权无关紧要。通常情况并非如此。
- 所有目录应为755或750。
- 所有文件应为644或640.例外：wp-config.php应为440或400，以防止服务器上的其他用户读取它。
- 不应该给777目录，甚至上传目录。由于php进程作为文件的所有者运行，因此它获得了所有者权限，甚至可以写入755目录。
在这种特定的类型设置中，WordPress将检测到它可以直接创建具有适当所有权的文件，因此在升级或安装插件时它不会要求FTP凭据。
sysadmins用于此设置的常用方法是：
- suPHP，通过php-cgi运行，目前自2013年以来一直没有维护。
- mod_ruid2，apache模块，自2013年以来一直未维护。
- mpm-itk，apache模块。
- mod_fcgid，Apache模块和FastCGI服务器，具有更广泛的配置。
- PHP-FPM，一种具有共享OPCode的替代FastCGI服务器，用于Apache和Nginx。
使用FTP客户端
FTP程序（“客户端”）允许您为远程主机上的文件和目录设置权限。通常调用此函数chmod或set permissions在程序菜单中调用此函数。
在WordPress安装中，您可能想要更改的两个文件是索引页面和控制布局的css 。以下是更改index.php 的方法 - 对于任何文件，该过程都是相同的。
在下面的屏幕截图中，查看最后一列 - 显示权限。它看起来有点令人困惑，但现在只需注意字母序列。
初始权限
右键单击“index.php”并选择“文件权限”
将出现一个弹出屏幕。
更改文件权限
不要担心复选框。只需删除'数字值：'并输入您需要的数字 - 在这种情况下它是666.然后单击确定。
权限已被更改
您现在可以看到文件权限已更改。
取消隐藏隐藏文件
默认情况下，大多数FTP客户端（包括FileZilla）都会显示隐藏文件，这些文件以句点（。）开头。但是，在某些时候，您可能需要查看隐藏文件，以便可以更改该文件的权限。例如，您可能需要创建.htaccess文件，即控制永久链接的文件，可写入。
要在FileZilla中显示隐藏文件，必须从顶部菜单中选择“查看”，然后选择“显示隐藏文件”。文件的屏幕显示将刷新，任何以前隐藏的文件都应该进入视图。
要使FileZilla始终显示隐藏文件 - 在“编辑”，“设置”，“远程文件列表”下，选中“始终显示隐藏文件”框。
在最新版本的Filezilla中，“显示隐藏文件”选项已移至“服务器”选项卡。选择“强制显示隐藏文件”。
使用命令行
如果您拥有对主机帐户的shell / SSH访问chmod权限，则可以使用更改文件权限，这是有经验的用户的首选方法。在开始使用之前，chmod建议您阅读一些教程，以确保您了解使用它可以实现的目标。设置不正确的权限可能会使您的网站脱机，所以请慢慢来。
您可以通过两个步骤使目录中的所有文件都可wp-content写，但在使每个文件和文件夹都可写之前，您应首先尝试更安全的替代方法，例如仅修改目录。首先尝试这些命令中的每一个，如果它们不起作用，则进行递归，这将使您的主题图像文件可写。将DIR替换为您要写入的文件夹
chmod -v 746 DIR chmod -v 747 DIR chmod -v 756 DIR chmod -v 757 DIR chmod -v 764 DIR chmod -v 765 DIR chmod -v 766 DIR chmod -v 767 DIR
如果那些不能允许你写，请按顺序再次尝试它们，除非这次用-R替换-v，它将递归地更改位于文件夹中的每个文件。如果之后你仍然无法写，你现在可以尝试777。
关于Chmod
chmod是一个unix命令，意思是文件中的“ ch ange mod e”。该-R标志表示将更改应用于其中的每个文件和目录wp-content。766是我们将目录更改为的模式，这意味着该目录可由WordPress以及系统上的任何和所有其他用户读写。最后，我们有了要修改的目录的名称wp-content。如果766不起作用，您可以尝试777，这使所有用户，组和进程可读，可写和可执行所有文件和文件夹。
如果您使用永久链接，您还应该更改.htaccess的权限，以确保WordPress可以在更改设置（如添加新页面，重定向，类别等）时更新它。这需要在mod_rewrite永久链接时更新.htaccess文件用过的。
- 转到WordPress的主目录
- 输入
chmod -v 666 .htaccess
注意：从安全角度来看，即使是少量保护也比世界可写目录更可取。从像744这样的低容许设置开始，直到它工作为止。如有必要，仅使用777，并且希望仅在一段时间内使用。
777的危险
此权限问题的关键是您的服务器的配置方式。您用于FTP或SSH进入服务器的用户名很可能不是服务器应用程序本身用于提供页面的用户名。
7 7 7 用户组世界 r + w + x r + w + x r + w + x 4 + 2 + 1 4 + 2 + 1 4 + 2 + 1 = 777
Apache服务器通常由www-data，dhapache或nobody用户帐户“拥有” 。这些帐户对服务器上的文件的访问权限有限，这是有充分理由的。通过将您的用户帐户拥有的个人文件和文件夹设置为World-Writable，您实际上可以将它们设为World Writable。现在，运行服务器，服务页面，执行php解释器等的www-data，dhapache和nobody用户将拥有对您的用户帐户文件的完全访问权限。
这为某人通过劫持服务器上的任何进程提供了访问您文件的途径，这也包括您计算机上的任何其他用户。因此，您应该仔细考虑修改计算机的权限。我从来没有遇到任何需要超过767的东西，所以当你看到777问为什么它是必要的。
最糟糕的结果
由于对文件夹甚至文件使用777权限而可能发生的最坏情况是，如果恶意破解者或实体能够上传狡猾的文件或修改当前文件以执行代码，他们将完全控制您的博客，包括您的数据库信息和密码。
找到解决方法
通常很容易获得令人印象深刻的WordPress插件提供的增强功能，而不必冒险。联系插件作者或您的服务器支持并请求解决方法。
查找安全文件权限
.htaccess文件是运行服务器的进程的所有者访问的文件之一。因此，如果您将权限设置得太低，那么您的服务器将无法访问该文件并导致错误。其中有找到最安全设置的方法。开始限制太多，并增加权限，直到它工作。
示例权限设置
以下示例具有自定义编译的php-cgi二进制文件和位于cgi-bin目录中的自定义php.ini文件，用于执行php脚本。为防止在Web浏览器中直接访问解释器和php.ini文件，它们受.htaccess文件保护。
默认权限（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
安全权限
600 -rw ------- /home/user/wp-config.php 6 0 4 -rw ---- r-- /home/user/cgi-bin/.htaccess 6 00 -rw --- ---- /home/user/cgi-bin/php.ini 7 11 -rwx - x - x /home/user/cgi-bin/php.cgi 100 --- x ------ /家庭/用户/ cgi-bin目录/ php5.cgi
.htaccess权限
644> 604 - 删除了允许.htaccess文件读取权限的组所有者的位。通常需要644并建议用于.htaccess文件。
php.ini权限
644> 600 - 以前所有可以访问服务器的组和所有用户都可以访问php.ini，即使只是从站点请求它。棘手的是因为php.ini文件仅由php.cgi使用，我们只需要确保php.cgi进程有权访问。php.cgi作为拥有这两个文件的同一用户运行，因此单个用户现在是唯一能够访问此文件的用户。
php.cgi权限
755> 711 此文件是一个已编译的php-cgi二进制文件，而不是mod_php或托管公司提供的默认vanilla php。此文件的默认权限为755。
php5.cgi权限
755> 100 - 由于用户帐户是运行php cgi的进程的所有者的设置，没有其他用户或组需要访问权限，因此我们禁用除执行访问权限之外的所有访问权限。这很有趣，因为它确实有效。您可以尝试读取文件，写入文件等，但您对此文件的唯一访问是运行php脚本。作为文件的所有者，您始终可以再次更改权限模式。
$ cat：php5.cgi：权限被拒绝 ./php5.cgi：欢迎
SELinux的
安全性增强型Linux是一个内核安全模块，它提供了将进程沙盒化到特定上下文的机制。这特别适用于限制网页可以在操作系统的其他部分上执行的操作。安全策略拒绝的操作通常很难与常规文件权限错误区分开来。
selinux通常安装在Redhat系列发行版上（例如，CentOS，Fedora，Scientific，Amazon等）。
如何确定selinux是否是问题？
如果您使用的是基于debian的发行版，那么您可能没问题。
运行以下命令（在基于rpm的系统上）;
#rpm -qa | grep selinux selinux-policy-targeted-3.13.1-166.el7_4.7.noarch selinux-policy-3.13.1-166.el7_4.7.noarch libselinux-2.5-11.el7.x86_64 libselinux-python-2.5-11 .el7.x86_64 libselinux-utils-2.5-11.el7.x86_64
并检查是否是拒绝权限的原因：
＃getenforce 执行
selinux导致的一个问题是阻止wp-admin工具写出url重写所需的`.htaccess`文件。有几个命令用于检查此行为
#audit2allow -w -a
type = AVC msg = audit（1517275570.388：55362）：avc：拒绝{write} for pid = 11831 comm =“httpd”path =“/ var / www / example.org / .htaccess”dev = “vda1”ino = 67137959 scontext = system_u：system_r：httpd_t：s0 tcontext = system_u：object_r：httpd_sys_content_t：s0 tclass = file
原因是：
boolean httpd_unified设置错误。
说明：
允许httpd统一
允许访问通过执行：
#setsebool -P httpd_unified 1
和
#ausearch -m avc -c httpd
----
time-> Tue Jan 30 01:30:31 2018
type = PROCTITLE msg = audit（1517275831.762：55364）：proctitle = 2F7573722F7362696E2F6874747064002D44464F524547524F554E44
type = SYSCALL msg = audit（1517275831.762：55364） ：arch = c000003e syscall = 21 success = no exit = -13 a0 = 55b9c795d268 a1 = 2 a2 = 0 a3 = 1 items = 0 ppid = 11826 pid = 11829 auid = 4294967295 uid = 48 gid = 48 euid = 48 suid = 48 fsuid = 48 egid = 48 sgid = 48 fsgid = 48 tty =（none）ses = 4294967295 comm =“httpd”exe =“/ usr / sbin / httpd”subj = system_u：system_r：httpd_t：s0 key =（null）
type = AVC msg = audit（1517275831.762：55364）：avc：拒绝{write} for pid = 11829 comm =“httpd”name =“bioactivator.org”dev =“vda1”ino = 67137958 scontext = system_u：system_r：httpd_t：s0 tcontext = unconfined_u：object_r：httpd_sys_content_t：s0 tclass = dir
----
您可以暂时禁用selinux以确定是否是问题的原因;
#setenforce usage：setenforce [强制执行| 许可| 1 | 0]