問題描述
我最近有一個問題，因為我沒有手動安裝或 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 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。