更改文件权限

在计算机文件系统上，不同的文件和目录具有指定谁和什么可以读取、写入、修改和访问它们的**权限。**这很重要，因为 WordPress 可能需要访问才能写入您wp-content目录中的文件以启用某些功能。

权限模式

 7      5      5
user   group  world
r+w+x  r+x    r+x
4+2+1  4+0+1  4+0+1  = 755

权限模式是通过为用户、文件组和其他所有人添加以下值来计算的。该图显示了如何。

  • R read 4 – 允许读取文件
  • 写入2 – 允许写入/修改文件
  • e X ecute1 – 读/写/删除/修改/目录
 7      4      4
user   group  world
r+w+x  r      r
4+2+1  4+0+0  4+0+0  = 744

示例权限模式

模式

烫发解释
0677-rw-rwxrwx所有者只有 rw(6)，其他和组有 rwx (7)
0670-rw-rwx—owner只有rw，group有rwx，其他没有权限
0666-rw-rw-rw-所有只有 rw (6)
0607-rw——-rwxowner 只有 rw，group 没有权限，其他人有 rwx
0600-rw——-owner只有rw权限，group和其他人没有权限
0477-r–rwxrwx所有者只读 (4)，其他和组有 rwx (7)
0470-r–rwx—owner只读，group有rwx，其他没有权限
0407-r——–rwxowner只读，other有rwx，group没有权限
0444-r–r–r–所有只读 (4)
0400-r——–owner只读(4)，group和其他人没有权限(0)

WordPress 的权限方案

权限因主机而异，因此本指南仅详细介绍一般原则。它不能涵盖所有情况。本指南适用于运行标准设置的服务器（注意，对于使用“suexec”方法的共享主机，请参见下文）。

通常，所有文件都应归您的 Web 服务器上的用户 (ftp) 帐户所有，并且该帐户应该是可写的。在共享主机上，文件永远不应属于网络服务器进程本身（有时是www或apache或nobody用户）。

任何需要 WordPress 写访问权限的文件都应该由 WordPress 使用的用户帐户（可能与服务器帐户不同）拥有或归组所有。例如，您可能有一个用户帐户可以让您通过 FTP 将文件来回传送到您的服务器，但您的服务器本身可能使用单独的用户在单独的用户组中运行，例如dhapache或nobody。如果 WordPress 作为 FTP 帐户运行，则该帐户需要具有写入权限，即，是文件的所有者，或者属于具有写入权限的组。在后一种情况下，这意味着权限设置比默认设置更宽松（例如，文件夹设置为 775 而不是 755，以及 664 而不是 644）。

WordPress 的文件和文件夹权限对于大多数用户来说应该是相同的，这取决于您执行的安装类型和安装时系统环境的 umask 设置。

**注意：**如果有经验的用户为您安装了 WordPress，您可能不需要修改文件权限。除非您遇到权限错误问题，或者您_想要这样做_，否则您可能不应该搞砸这个。

**注意：**如果您自己安装了 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
|   |- cache
|   |- plugins
|   |- themes
|   |- uploads
|- wp-cron.php
|- wp-includes
|- xmlrpc.php

与 suexec 共享主机

以上可能不适用于使用“suexec”方法运行 PHP 二进制文件的共享主机系统。这是许多网络主机使用的流行方法。对于这些系统，php 进程作为 php 文件本身的所有者运行，从而为共享主机的特定情况提供更简单的配置和更安全的环境。

注意：suexec 方法不应在单站点服务器配置上使用，它们仅在共享主机的特定情况下更安全。

在这样的 suexec 配置中，正确的权限方案很容易理解。

  • 所有文件都应归实际用户帐户所有，而不是用于 httpd 进程的用户帐户。
  • 组所有权无关紧要，除非对 Web 服务器进程权限检查有特定的组要求。通常情况并非如此。
  • 所有目录都应为 755 或 750。
  • 所有文件都应为 644 或 640。例外：wp-config.php 应为 440 或 400，以防止服务器上的其他用户读取它。
  • 任何目录都不应该被赋予 777，即使是上传目录。由于 php 进程作为文件的所有者运行，它获得所有者权限，甚至可以写入 755 目录。

在这种特定类型的设置中，WordPress 会检测到它可以直接创建具有适当所有权的文件，因此在升级或安装插件时不会要求提供 FTP 凭据。

系统管理员为此设置使用的流行方法是：

  • 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建议您阅读一些教程，以确保您了解使用它可以实现什么。设置不正确的权限可能会使您的站点脱机，因此请慢慢来。

  • Unix 权限

您可以分两步使目录中的所有文件都可写，但在使每个文件和文件夹都可写之前，您应该首先尝试更安全的替代方法，例如只修改目录。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

如果这些都不允许您写入，请按顺序重试，除了这次将 -v 替换为 -R，这将递归地更改位于文件夹中的每个文件。如果之后你还是不会写，你现在可以试试777。

关于 Chmod

chmod是一个 unix 命令，表示对文件进行“更改模式”。该标志意味着将更改应用到. 766 是我们将目录更改为的模式，这意味着该目录可由 WordPress 以及您系统上的任何和所有其他用户读取和写入。最后，我们有了要修改的目录的名称，. 如果 766 不起作用，您可以尝试 777，它使所有文件和文件夹对所有用户、组和进程都可读、可写和可执行。-R``wp-content``wp-content

如果您使用永久链接，您还应该更改 .htaccess 的权限，以确保当您更改设置（例如添加新页面、重定向、类别等）时 WordPress 可以更新它。这需要在 mod_rewrite 永久链接正在运行时更新 .htaccess 文件用过的。

  1. 转到WordPress的主目录
  2. 进入chmod -v 666 .htaccess

**注意：**从安全的角度来看，即使是少量的保护也比全局可写目录更可取。从 744 等低许可设置开始，逐步提高直到它起作用。仅在必要时使用 777，并且希望只使用一段时间。

777的危险

这个权限问题的症结在于你的服务器是如何配置的。您用于通过 FTP 或 SSH 进入服务器的用户名很可能不是服务器应用程序本身用于提供页面的用户名。

 7      7      7
user   group  world
r+w+x  r+w+x  r+w+x
4+2+1  4+2+1  4+2+1  = 777

Apache 服务器通常由www-data、dhapache或nobody用户帐户“拥有” 。这些帐户对服务器上的文件的访问权限有限，这是有充分理由的。通过将您的用户帐户拥有的个人文件和文件夹设置为全球可写，您实际上是在将它们设为全球可写。现在，运行您的服务器、服务页面、执行 php 解释器等的 www-data、dhapache 和 nobody 用户将拥有对您的用户帐户文件的完全访问权限。

这为某人提供了一种途径，可以通过基本上劫持您服务器上的任何进程来访问您的文件，这也包括您机器上的任何其他用户。所以你应该仔细考虑修改你机器上的权限。我从来没有遇到过需要超过 767 的东西，所以当你看到 777 时问问为什么它是必要的。

最坏的结果

对文件夹甚至文件使用 777 权限可能发生的最坏情况是，如果恶意破解者或实体能够上传不正当文件或修改当前文件以执行代码，他们将完全控制您的博客，包括拥有您的数据库信息和密码。

寻找解决方法

通常很容易获得令人印象深刻的 WordPress 插件提供的增强功能，而不必冒着风险。联系插件作者或您的服务器支持并请求解决方法。

查找安全文件权限

.htaccess 文件是运行服务器的进程的所有者访问的文件之一。因此，如果您将权限设置得太低，那么您的服务器将无法访问该文件并会导致错误。这就是找到最安全设置的方​​法。开始过于严格并增加权限直到它起作用。

示例权限设置

以下示例有一个_自定义编译的 php-cgi 二进制文件_和一个位于 cgi-bin 目录中的_自定义 php.ini文件，用于执行 php 脚本。_php.ini为了防止在 Web 浏览器中直接访问解释器和文件，它们受到 .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------  /home/user/cgi-bin/php5.cgi

.htaccess 权限

644 > 604 – 删除了允许 .htaccess 文件读取权限的组所有者的位。对于 .htaccess 文件，通常需要并建议使用 644。

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: Permission denied
./php5.cgi:  Welcome

SELinux

Security Enhanced 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
Enforcing

selinux 导致的一个问题是阻止 wp-admin 工具写出 url 重写所需的 .htaccess 文件。有几个命令可用于检查此行为

$ audit2allow -w -a
type=AVC msg=audit(1517275570.388:55362): avc:  denied  { 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
        Was caused by:
        The boolean httpd_unified was set incorrectly.
        Description:
        Allow httpd to unified
        Allow access by executing:
        # 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:  denied  { 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 \[ Enforcing | Permissive | 1 | 0 \]

变更日志

  • 2022-09-11：更改文件权限的原始内容。