執行Nginx -t會導致文件所有者權限變為Nobody，你知道嗎？
故障現象
最近生產環境出現了1次app應用登錄異常的故障，最后定位分析發現是因為在root用戶下執行過nginx -t命令導致部分文件目錄（1、fastcgi、proxy、scgi、uwsgi）所有者權限變為nobody導致。其實在nginx應用的error日志中也發現有大量權限問題的相關報錯：[crit] 123744#0: *172221779 open() "/app/nginx20/1/21/0118488121" failed (13: Permission denied)，只不過一開始沒引起重視，因為查看有權限報錯的這些目錄下并沒有任何文件，加上也咨詢過研發認為沒有影響，所以導致一開始的排查方向出現了偏差，最終導致此次故障還是經歷了好幾個小時。
原因分析
那么為什么執行nginx -t命令會導致臨時文件所有者權限變為nobody，這才是寫這篇文章的目的，下面進行測試。Nginx -t命令官方解釋如下：
按照官網對nginx -t命令的解釋，該命令只是去檢查配置文件語法，并打開配置文件中預定義文件，按照這個字面意思理論上該命令不會對文件目錄權限進行修改，但是在實際測試過程中發現使用普通用戶如app運行nginx服務，并且nginx配置文件nginx.conf中沒有配置user xxx參數內容時，如果使用root用戶執行nginx -t命令，則會導致臨時文件（fastcgi、scgi、uwsgi、client_body、proxy）目錄權限所有者被更改為nobody，這使得啟動 nginx 服務的用戶失去了對這些目錄的訪問權限，從而引發應用程序的部分頁面無法訪問的問題。觸發此問題的具體條件如下：：
1）nginx服務進程使用非root和nobody用戶啟動；
2）nginx配置文件nginx.conf中缺少啟動用戶的定義：即配置文件中沒有包含user app;這樣的行來指定nginx服務啟動時所使用的用戶
3）使用root用戶執行了nginx -t命令：這可能會在上述兩個條件下更改臨時目錄的所有者為 nobody
測試驗證
為了驗證上述結論是否成立，我們進行以下測試驗證。在/opt目錄下安裝了一個nginx應用，授權所有文件歸屬user及group為app用戶。
[root@localhost opt]# chown -R app.app /opt/nginx20/
[root@localhost opt]# ll /opt/nginx20/
total 36K
drwx------ 2 app app 4.0K Aug 27 20:50 client_body_temp
drwxr-xr-x 2 app app 4.0K Aug 27 22:29 conf
drwx------ 2 app app 4.0K Aug 27 20:50 fastcgi_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 html
drwxr-xr-x 2 app app 4.0K Aug 27 22:34 logs
drwx------ 2 app app 4.0K Aug 27 20:50 proxy_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 sbin
drwx------ 2 app app 4.0K Aug 27 20:50 scgi_temp
drwx------ 2 app app 4.0K Aug 27 20:50 uwsgi_temp然后我們切換到app用戶來啟動nginx（此時nginx.conf配置文件中是未配置 user app;內容的）
[root@localhost nginx20]# su - app
[app@localhost ~]$ /opt/nginx20/sbin/nginx -c /opt/nginx20/conf/nginx.conf
[app@localhost ~]$ ps -ef | grep nginx
app 1712 1 0 21:46 ? 00:00:00 nginx: master process /opt/nginx20/sbin/nginx -c /opt/nginx20/conf/nginx.conf
app 1713 1712 0 21:46 ? 00:00:00 nginx: worker process
app 1715 1660 0 21:47 pts/0 00:00:00 grep --color=auto nginx接下來再次切換到root用戶執行nginx -t命令
[root@localhost nginx20]# ll
total 36K
drwx------ 2 app app 4.0K Aug 27 20:50 client_body_temp
drwxr-xr-x 2 app app 4.0K Sep 29 21:46 conf
drwx------ 2 app app 4.0K Aug 27 20:50 fastcgi_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 html
drwxr-xr-x 2 app app 4.0K Sep 29 21:46 logs
drwx------ 2 app app 4.0K Aug 27 20:50 proxy_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 sbin
drwx------ 2 app app 4.0K Aug 27 20:50 scgi_temp
drwx------ 2 app app 4.0K Aug 27 20:50 uwsgi_temp
#上面是執行nginx -t命令之前的文件權限
[root@localhost nginx20]# /opt/nginx20/sbin/nginx -t
nginx: the configuration file /opt/nginx20/conf/nginx.conf syntax is ok
nginx: configuration file /opt/nginx20/conf/nginx.conf test is successful
# 下面是執行nginx -t命令之后的文件權限
[root@localhost nginx20]# ll
total 36K
drwx------ 2 nobody app 4.0K Aug 27 20:50 client_body_temp
drwxr-xr-x 2 app app 4.0K Sep 29 21:46 conf
drwx------ 2 nobody app 4.0K Aug 27 20:50 fastcgi_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 html
drwxr-xr-x 2 app app 4.0K Sep 29 21:46 logs
drwx------ 2 nobody app 4.0K Aug 27 20:50 proxy_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 sbin
drwx------ 2 nobody app 4.0K Aug 27 20:50 scgi_temp
drwx------ 2 nobody app 4.0K Aug 27 20:50 uwsgi_temp通過上述測試證實了前面說的3點：
1）nginx服務進程使用非root和nobody用戶啟動；
2）nginx配置文件nginx.conf中缺少啟動用戶的定義：即配置文件中沒有包含user app;
3）使用root用戶執行了nginx -t命令：
這種情況下會更改某些目錄的所有者權限為nobody，上面的client_body_temp、fastcgi_temp、proxy_temp、scgi_temp、uwsgi_temp目錄文件所有者權限均變為了nobody。
接下來再來驗證下在配置文件中配置啟動用戶的情況，在nginx配置文件中配置user app;內容（指定nginx啟動用戶為app）
[root@localhost nginx20]# vim /opt/nginx20/conf/nginx.conf
[root@localhost nginx20]# head -5 /opt/nginx20/conf/nginx.conf
user app;
worker_processes 1;
......然后直接通過root用戶啟動nginx服務,可以發現nginx的worker進程運行用戶為app，此時nginx安裝路徑下的文件權限也為app，前面*temp的幾個文件開始所有者權限為nobody，在配置文件配置user app內容后重新啟動權限也隨之改變了過來，說明 user app配置內容是生效的。
[root@localhost nginx20]# ps -ef | grep nginx
root 1760 1 0 22:04 ? 00:00:00 nginx: master process /opt/nginx20/sbin/nginx -c /opt/nginx20/conf/nginx.conf
app 1761 1760 0 22:04 ? 00:00:00 nginx: worker process
root 1763 1326 0 22:04 pts/0 00:00:00 grep --color=auto nginx
[root@localhost nginx20]# ll
total 36K
drwx------ 2 app app 4.0K Aug 27 20:50 client_body_temp
drwxr-xr-x 2 app app 4.0K Sep 29 22:02 conf
drwx------ 2 app app 4.0K Aug 27 20:50 fastcgi_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 html
drwxr-xr-x 2 app app 4.0K Sep 29 22:04 logs
drwx------ 2 app app 4.0K Aug 27 20:50 proxy_temp
drwxr-xr-x 2 app app 4.0K Aug 27 20:49 sbin
drwx------ 2 app app 4.0K Aug 27 20:50 scgi_temp
drwx------ 2 app app 4.0K Aug 27 20:50 uwsgi_temp接下來我們在不停nginx服務的情況下通過chown命令直接改變文件的歸屬權限，然后再次執行nginx -t命令看看
[root@localhost nginx20]# useradd -s /sbin/nologin weihu
[root@localhost nginx20]# chown -R weihu.weihu /opt/nginx20/
[root@localhost nginx20]# ll
total 36K
drwx------ 2 weihu weihu 4.0K Aug 27 20:50 client_body_temp
drwxr-xr-x 2 weihu weihu 4.0K Sep 29 22:02 conf
drwx------ 2 weihu weihu 4.0K Aug 27 20:50 fastcgi_temp
drwxr-xr-x 2 weihu weihu 4.0K Aug 27 20:49 html
drwxr-xr-x 2 weihu weihu 4.0K Sep 29 22:04 logs
drwx------ 2 weihu weihu 4.0K Aug 27 20:50 proxy_temp
drwxr-xr-x 2 weihu weihu 4.0K Aug 27 20:49 sbin
drwx------ 2 weihu weihu 4.0K Aug 27 20:50 scgi_temp
drwx------ 2 weihu weihu 4.0K Aug 27 20:50 uwsgi_temp
#上面直接新建了一個weihu用戶然后授權/opt/nginx20/及其下的所有文件歸屬為weihu用戶
#下面直接在root用戶下執行nginx -t命令
[root@localhost nginx20]# /opt/nginx20/sbin/nginx -t
nginx: the configuration file /opt/nginx20/conf/nginx.conf syntax is ok
nginx: configuration file /opt/nginx20/conf/nginx.conf test is successful
[root@localhost nginx20]# ll
total 36K
drwx------ 2 app weihu 4.0K Aug 27 20:50 client_body_temp
drwxr-xr-x 2 weihu weihu 4.0K Sep 29 22:02 conf
drwx------ 2 app weihu 4.0K Aug 27 20:50 fastcgi_temp
drwxr-xr-x 2 weihu weihu 4.0K Aug 27 20:49 html
drwxr-xr-x 2 weihu weihu 4.0K Sep 29 22:04 logs
drwx------ 2 app weihu 4.0K Aug 27 20:50 proxy_temp
drwxr-xr-x 2 weihu weihu 4.0K Aug 27 20:49 sbin
drwx------ 2 app weihu 4.0K Aug 27 20:50 scgi_temp
drwx------ 2 app weihu 4.0K Aug 27 20:50 uwsgi_temp通過上述測試可以發現即使nginx的相關文件所有者權限為其他用戶，如果在配置文件中配置了user app;內容，那么在執行nginx -t 命令后，部分文件的所有者權限仍舊會改變為app用戶。
注意：這里的部分文件是指nginx運行時產生的臨時文件，如上面提到的client_body_temp、fastcgi_temp、proxy_temp、scgi_temp、uwsgi_temp等目錄文件，有關這類臨時文件用途說明如下：
- client_body_temp：這個目錄用于存儲客戶端請求中的大請求體（如 POST 請求）。當客戶端發送的數據量超過一定閾值時，Nginx 會將這部分數據寫入磁盤上的臨時文件中，以防止占用過多內存。
- fastcgi_temp：這個目錄用于存儲通過 FastCGI 協議傳遞的數據。當 Nginx 作為 FastCGI 網關時，它可能會將從后端應用程序接收到的響應數據暫時保存在這個目錄中。
- proxy_temp：這個目錄用于存儲通過代理（Proxy）傳遞的數據。當 Nginx 作為反向代理服務器時，它可能會將從后端服務器接收到的響應數據暫時保存在這個目錄中。
- scgi_temp：這個目錄用于存儲通過 SCGI 協議傳遞的數據。SCGI（Simple Common Gateway Interface）是一種類似于 FastCGI 的協議，用于 Web 服務器和應用程序之間的通信。Nginx 可能會將通過 SCGI 接收到的數據暫時保存在這里。
- uwsgi_temp：這個目錄用于存儲通過 uWSGI 協議傳遞的數據。uWSGI 是一個通用的應用程序服務器，支持多種協議，包括 uWSGI 協議、FastCGI 協議等。Nginx 可能會將通過 uWSGI 接收到的數據暫時保存在這個目錄中。
這些臨時目錄的主要目的是為了提高性能并避免內存溢出。通過將部分數據存儲在磁盤上，Nginx 可以有效地處理大請求和響應數據，而不會消耗過多的內存資源。
配置建議
為了防止這種情況發生，生產環境還是建議在nginx配置文件中明確指定nginx應用啟動用戶（如user app;），這將即可避免因錯誤的執行了nginx -t命令而導致臨時文件權限異常進而觸發業務異常的情況出現。
