在《運維排查篇 | 通路nginx出現403錯誤》中，我列舉了四個相關的排障思路以及解決方法（沒看過的朋友可以點選連結看一下）
在釋出了文章之後，我一直覺得第三個排障思路，也就是在解決nginx工作使用者和啟動使用者不一緻的問題上始終沒有找到更好的方法
一般來講，nginx的 master 程序由 root 使用者開啟，負責管理 worker 程序，而 worker 程序見名知意，就是用來幹活工作的，一般由 nginx 使用者負責。
[[email protected] ~]# ps -aux | grep nginx
root 12340.00.21067845168 ? Ss Jun17 0:00 nginx: master process nginx
nginx 34910.00.21067884212 ? S 15:19 0:00 nginx: worker process
nginx 34920.00.21067884212 ? S 15:19 0:00 nginx: worker process
而這個工作使用者是可以定義的，在 nginx 的配置檔案裡面修改
nginx配置檔案：/usr/local/nginx/conf/nginx.conf
在我最初的文章中，我提供的解決辦法是将 nginx 的工作使用者修改為 root，跟啟動使用者一緻，這樣就能解決權限問題，但是這樣會産生安全隐患
一旦黑客入侵了80端口，那麼他就擁有了 root 權限，是以不建議修改工作使用者為root
那麼有沒有更好的辦法呢？在工作使用者不是 root 使用者的前提下還能使得 nginx 使用者可以啟動 master 程序
這天早上，我在上班路上看着這本書，突然看到書上有個案例吸引了我，我大緻講一下
錯誤現象：客戶的一台web伺服器是基于Apache+JK+Tomcat建構的一個電商平台，客戶反映Apache無法啟動，但是Tomcat可以啟動。并且發現是權限問題導緻
作者經過排查後，發現Apache的啟動使用者是www，監聽端口為80，并查到/usr/local/apache2目錄所有檔案和目錄權限都是www，不是讀寫權限的問題。
最後定位到是Apache的工作使用者是www，無法使用80端口，linux做了一些安全限制，使得普通使用者無法綁定這類端口
根據定位到的問題，這裡有兩個解決方法
- 将Apache以 root 使用者運作，簡單粗暴
- 修改Apache目錄下httpd檔案的SUID屬性
看到這裡，我突然想到跟我之前寫過的一篇案例中出現的問題有異曲同工之妙，于是有了今天這篇2.0版本
解決方法2.0
上文我說過：有沒有更好的解決方法，使得工作使用者為 nginx 的前提下還能正常啟動 master 程序
除了我一開始寫的修改工作使用者為 root 之外，現在有更好的方法，那就是：
修改nginx目錄下啟動檔案的SUID屬性
我們先來看下如何操作
首先将nginx啟動程式賦予s權限
chmod u+s /usr/local/nginx/sbin/nginx
接着将該檔案的所有者改為 root
chown root /usr/local/nginx/sbin/nginx
這樣就成功解決啦！
看到這裡，可能有些小夥伴已經一臉懵逼了，這個SUID屬性是啥，s權限又是啥
接下來我們簡單介紹下linux系統中的特殊權限
Linux系統中的檔案的s權限
我們在linux系統中最常見的檔案權限分别是：r、w、x，分别對應着讀、寫、執行權限，這三個權限相信大家都懂了，這裡就不過多介紹。
除此之外，linux還支援另外一系列的權限設定，就比如上文所介紹到的 s 權限
s，表示set UID或set GID。位于user或group權限組的第三位置。
如果在user權限組中設定了s位，則當檔案被執行時，該檔案是以檔案所有者UID而不是使用者UID 執行程式。
如果在group權限組中設定了s位，當檔案被執行時，該檔案是以檔案所有者GID而不是使用者GID執行程式
需要注意的是，在給檔案設定 s 權限的時候，該檔案必須已經具備了可執行權限（x），這樣 s 權限的設定才有效，并且檢查檔案權限的時候會出現”s“字樣
隻給檔案賦予s權限，系統是不會自動讓該檔案具備可執行權限的且檢查檔案權限的時候會出現”S“字樣
回到上面的案例，我們在給nginx啟動程式賦予 s 權限并且将啟動程式的所有者修改為 root 之後，當 nginx 使用者去啟動 nginx 的時候，它會去臨時獲得 root 使用者（該檔案所有者）的權限去啟動 nginx 程序
這樣就可以解決啟動使用者跟工作使用者不一緻而導緻權限問題啦