问题描述
我最近有一个问题，因为我没有手动安装或 One-Click 安装选项可用，我无法安装 WP Smush Pro 插件。
我碰到了 this post，建议调整 wp-config.php 的设置。我添加了建议的设置，但是似乎最重要的是：
define('FS_METHOD', 'direct');
我想知道的是将 FS_METHOD 设置为 direct 有什么真正的问题？安装插件还有其他替代方法吗？
这是官方文件所说的：
FS_METHOD forces the filesystem method. It should only be “direct”, “ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change this if you are experiencing update problems. If you change it and it doesn’t help, change it back/remove it. Under most circumstances, setting it to ‘ftpsockets’ will work if the automatically chosen method does not.
(Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security issues on poorly configured hosts, This is chosen automatically when appropriate.
最佳解决方案
这只是我如何理解 WordPress File API 的想法。如果是错误的，请 downvote 🙂
好的。如果您上传文件，则该文件拥有所有者。如果您使用 FTP 上传文件，则您登录，该文件将由 FTP 用户拥有。由于您拥有凭据，您可以通过 FTP 更改这些文件。所有者通常可以执行，删除，更改等文件。当然，您可以通过更改 file permissions 进行更改。
如果您使用 PHP 上传文件，则正在执行 PHP 的 linux 用户拥有该文件。该用户现在可以编辑，删除，执行等文件。只要您是用户，您的系统正在执行 PHP 即可，这是可以的。
假设您正在配置一个”poorly” 共享主机。很多人在这个系统上运行他们的 PHP 网站。让我们说只有一个 linux 用户正在为所有这些人执行 PHP 。这个共享主机上的一名网站管理员有不好的意图。他看到你的页面，他找出你的 WordPress 安装的路径。例如，WP_DEBUG 设置为 true，并且出现错误消息
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1
“Ha!” 坏男孩说。让我们看看，如果这个人把 FS_METHOD 设置为 direct，他会写一个脚本
<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>
由于只有一个用户正在运行 PHP，而且该用户也被坏男孩使用，所以如果您已经通过 PHP 上传了这些文件，并且通过附加的 PHP 用户作为所有者，他可以修改/删除/执行系统上的文件。
您的网站被黑客入侵
或者，正如在食品法典中所说的那样：
Many hosting systems have the webserver running as a different user than the owner of the WordPress files. When this is the case, a process writing files from the webserver user will have the resulting files owned by the webserver’s user account instead of the actual user’s account. This can lead to a security problem in shared hosting situations, where multiple users are sharing the same webserver for different sites.
次佳解决方案
有什么风险？
在配置不当的共享主机上，每个客户的 PHP 都将作为同一用户执行 (假设 apache 进行讨论) 。这个设置令人惊讶的常见。
如果您是这样的主机，并使用 WordPress 使用直接文件访问安装插件，则所有插件文件都将属于 apache 。同一服务器上的合法用户将能够通过编写将恶意代码注入插件文件的 PHP 脚本来攻击您。他们将脚本上传到自己的网站并请求其 URL 。您的代码成功受损，因为它们的脚本以 apache 运行，与拥有您的插件文件相同。
FS_METHOD 'direct'与它有什么关系？
当 WordPress 需要安装文件 (例如插件) 时，它使用 get_filesystem_method()函数来确定如何访问文件系统。如果您没有定义 FS_METHOD，它将为您选择一个默认值，否则它将使用您的选择，只要它是有意义的。
默认行为将会尝试检测您是否处于 at-risk 环境中，如上所述，如果您认为您安全，则将使用'direct'方法。在这种情况下，WordPress 将直接通过 PHP 创建文件，使它们属于 apache 用户 (在本示例中) 。否则会回到更安全的方法，例如提示您输入 SFTP 凭据，并按照您的要求创建文件。
FS_METHOD = 'direct'要求 WordPress 绕过该 at-risk 检测，并始终使用'direct'方法创建文件。
那为什么用 FS_METHOD = 'direct'？
不幸的是，用于检测 at-risk 环境的 WordPress 的逻辑是有缺陷的，并且产生 false-positives 和 false-negatives 。哎呦。测试涉及创建一个文件并确保它属于与其所在目录相同的所有者。假设如果用户相同，则 PHP 作为您自己的帐户运行，并且可以安全地插入该帐户。如果它们不同，WordPress 假定 PHP 作为共享帐户运行，并且安装插件是不安全的。不幸的是，这些假设都是受到教育的猜测，这些猜测往往是错误的。
您将使用 define( FS_METHOD = 'direct' ); 在这种假阳性场景中：您是成员全部通过自己的帐户上传文件的值得信赖的团队的一部分。 PHP 作为自己的单独用户运行。 WordPress 会假设这是一个 at-risk 环境，不会默认为'direct'模式。实际上，它只与您信任的用户共享，因此'direct'模式是安全的。在这种情况下，您应该使用 define( FS_METHOD = 'direct' ); 强制 WordPress 直接写入文件。
参考文献
注：本文内容整合自 Google/Baidu/Bing 辅助翻译的英文资料结果。如果您对结果不满意，可以加入我们改善翻译效果：薇晓朵技术论坛。