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