核心總結：php-fpm/apache 進程所使用的用戶，不能是網站文件所有者。 凡是違背這個原則，則不符合最小權限原則。
根據生產環境不斷反饋，發現不斷有 php網站被掛木馬，絕大部分原因是因為權限設置不合理造成。因為服務器軟件，或是 php 程序中存在漏洞都是難免的，在這種情況下，如果能正確設置 Linux 網站目錄權限， php 進程權限，那么網站的安全性實際上是可以得到保障的。
那么，造成網站被掛木馬的原因是什么？
1. ftp 連接信息被破解，對這個原因，可行的辦法就是使用非常復雜的FTP 用戶名（不要使用常用的用戶名），如果是固定作業，可考慮使用 iptables 防火牆限制來源 IP 。但是一些情景下，可能需要使用 VPN 以便遠程維護。 即網站維護者需要使用 FTP 修改網站文件時，必須先登錄到 IDC 機房的 VPN 服務器上，再進行后續的操作。
2. 網站服務器軟件/ 配置 /php 程序存在漏洞，被利用
在討論這個問題前，先說明文件及進程權限的幾個概念:
A. FTP用戶對網站目錄具有最大修改權限，那么網站的文件所有者一定屬於 FTP, 這是毋庸置疑的 , 否則如何修改文件呢？
B. php-fpm/apache/nginx 進程對網站文件至少需要有讀取權限，例如，以下命令即可查看這兩個進程所使用的賬號：
通過上圖，我們可以發現，nginx 和 php-fpm 子進程賬號是 nobody 。
我們再查看網站文件目錄的權限： 
發現網站文件所有者是www 賬號，那說明：
| nginx和 php 對網站只有讀取權限，無寫入權限
l 如果php 程序需要對網站某些文件有寫入權限，需要手工將文件或目錄權限修改為 777
l 因為php-fpm 子進程是以 nobody 運行，那么 php-fpm 生成的新文件所有者也是 nobody, 這時 ftp 用戶將無法修改這些文件，解鈴還需系鈴人，當 php 生成文件后，需要調用 chmod("/somedir/somefile", 0777) 將文件權限修改為 777 ，以便 FTP 用戶也可以修改這個文件。
l 經常有開發人員找我請求重設php 生成的文件的權限。
l 如果php-fpm/apache/nginx進程以網站文件所有者用戶運行，那意味着 php-fpm/apache/nginx 進程對整個網站目錄具有可寫權限，噩夢也就由此開始。
但是我們發現，有不少系統管理員為了省事，違背了Linux 最小化權限的原則，設置 php-fpm/apache/nginx進程以網站文件所有者賬號運行，當然這樣可能會方便 php 開發人員（ php-fpm 進程對整個網站目錄具有可寫權限），但是這樣一來， Linux 體系的文件系統權限原則將被打破，所有的安全措施將形同虛設。可以想象的是，萬一 php 程序中有漏洞，攻擊者上傳木馬，便可以修改網站的所有文件，網站首頁被黑，也就不足為怪了。
退一步，如果我們設置了較嚴格的權限，就算php 程序中存在漏洞，那么攻擊者也只能篡改權限為 777 的目錄，其它的文件是無法被改寫的，網站不就就得更安全了嗎？
核心總結：php-fpm/apache/nginx進程所使用的用戶，不能是網站文件所有者。 凡是違背這個原則，則不符合最小權限原則。
經過我參閱網上關於nginx, php-fpm 配置的文章教程和市面上的一些書籍，發現有不少人受這些文章的誤導，直接讓 php-fpm/apache/nginx進程以網站所有者賬號運行，例如張宴的《實戰 nginx 取代 apache 的高性能 Web 服務器》一書的 52 頁中，存在以下設置：
<value name="user">www</value>
<value name="group">www</value>
而在第50 頁，設置網站文件所有者也為 www 用戶：
chown -R www:www /data0/htdocs/blog
顯然，此書的這部分內部，對初學者有誤導，針對這個問題，我已經向本書作者發郵件，希望其能在第二版中進行強調聲明，以免由於過度寬松的權限配置，造成一些安全隱患。
官方提供的配置文件中，php-fpm 子進程使用 nobody 用戶，這完全是合理的，無須修改。
那么nginx 的子進程用戶，如何設置合理？ 我的建議是也使用 nobody （對錯誤日志寫入等無影響），設置方法如下：
nginx.conf文件第一行設置為 user nobody; , 再執行 nginx -s reload 即可。
php-fpm子進程用戶設置方法：
編輯文件php-fpm.conf （一般位於 /usr/local/php/etc/php-fpm.conf, 視安裝參數為准），找到 user 、group 兩個參數的定義，將其設置為nobody( 默認已經是 nobody) ，再重啟 php-fpm 進程即可。
網站可寫目錄的特殊注意
這里的可寫，是相對php-fpm 子進程而言。一個網站最容易出安全問題的即是可寫目錄，如果可寫目錄權限能控制嚴格，安全系數也將大大提高。
我們認為，一個網站可寫目錄主要分為以下幾種：
1. php 數據緩存目錄，如 discuz 的 forumdata 目錄，就存放了大量數據緩存文件。此類目錄一般會禁止用戶直接訪問，但是 discuz 在這個目錄下又存放了不少 js, css 文件，我們並不能簡單地拒絕用戶訪問這個目錄。顯然，這個目錄下的所有文件，不能直接交給 php 解析，我們后面會給出解決方案。
2. 附件上傳目錄。顯然此類目錄需要開啟訪問，但不能交由php 引擎解析（即這個目錄下的所有文件均視為普通靜態文件）。
3. 靜態文件生成目錄，這類目錄下的文件全部應視為靜態文件。
4. 日志目錄， 一般都會拒絕用戶直接訪問之。
也就是說對網站開發人員而言，需要對可寫目錄實現動靜分離，不同性能的文件，應該區別對待之，這樣也就方便系統管理員，設置合理的nginx 規則，以提高安全性。
簡單地去掉php 文件的執行權限，並不能阻止 php-fpm 進程解析之。
接下來，根據以上總結，系統管理員如何配置nginx 的目錄規則，才更安全呢？
1. 數據緩存目錄 /cache/
這個目錄的特點是需要777 權限，無須提供給用戶訪問，那么可以按以下參考配置 nginx
location ~ "^/cache" {
return 403;
}
location ~ "\.php$" {
fastcgi_pass 127.0.0.0:9000;
....................
}
這時，任何用戶將無法訪問/cache/ 目錄內容，即使
2. 附件上傳目錄 attachments
此目錄的特點是需要開放訪問權限，但所有文件不能由php 引擎解析（包括后綴名改為 gif 的木馬文件）
location ~ "^/attachments" {
}
location ~ "\.php$" {
fastcgi_pass 127.0.0.0:9000;
....................
}
注意，上面對attachments 目錄的 location 定義中是沒有任何語句的。 nginx 對正則表達式的location 匹配優先級最高，任何一個用正則表達式定義的 location, 只要匹配一次，將不會再匹配其它正則表達式定義的 location 。
現在，請在attachments 目錄下建立一個 php 腳本文件，再通過瀏覽器訪問安，我們發現瀏覽器提示下載，這說明 nginx 把 attachments 目錄下的文件當成靜態文件處理，並沒有交給 php fastcgi 處理。這樣即使可寫目錄被植入木馬，但因為其無法被執行，網站也就更安全了。
顯然，重要的php 配置文件，請勿放在此類目錄下。
3. 靜態文件生成目錄 public
這些目錄一般都是php 生成的靜態頁的保存目錄，顯然與附件目錄有類似之處，按附件目錄的權限設置即可。
可以預見的是，如果我們設置了較嚴格的權限，即使網站php 程序存在漏洞，木馬腳本也只能被寫入到權限為 777 的目錄中去，如果配合上述嚴格的目錄權限控制，木馬也無法被觸發運行，整個系統的安全性顯然會有顯著的提高。
但是網站可寫目錄的作用及權限，只有開發人員最為清楚。這方面需要php 開發人員和系統管理員積極溝通。我們使用的方式是：項目上線前，開發人員根據以文檔形式提供網站可寫目錄的作用及權限，由系統管理員針對不同目錄進行權限設置。任何一方修改了網站目錄權限，但未體現到文檔中，我們認為是違反工作流程的。