FileZilla-02
WordPress的權限方案
通常，所有文件應由您的Web服務器上的用戶（ftp）帳戶擁有，並且應該可由該帳戶寫入。在共享主機上，文件永遠不應歸Web服務器進程本身所有（有時這是www，或apache，或nobody用戶）。
對於大多數用戶，WordPress的文件和文件夾權限應該相同，具體取決於您在安裝時執行的安裝類型和系統環境的umask設置。
註意： 如果您自己安裝了WordPress，則可能需要修改文件權限。某些文件和目錄應該使用更嚴格的權限“強化”，特別是wp-config.php文件。該文件最初是使用644權限創建的，如此保留是危險的。
通常，所有核心WordPress文件只能由您的用戶帳戶（或httpd帳戶，如果不同）寫入。（有時候，多個ftp帳戶用於管理安裝，如果所有ftp用戶都是已知且受信任的，即不是共享主機，那麽分配可寫組可能是合適的。請向服務器管理員咨詢更多信息。）但是，如果您使用mod_rewrite永久鏈接
/.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建議您閱讀一些教程，以確保您了解使用它可以實現的目標。設置不正確的權限可能會使您的網站脫機，所以請慢慢來。
- Unix權限
- Apple 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]
FileZilla-02