我從 fedora 2 開始玩到現在的 Centos 7 ，越到後面在用網頁伺服器時最常遇到的就是在透過網頁端上傳資料到伺服端時的權限問題。
印象中很早前好像還沒有 SELinux 的保護機制，然後直到開始使用這個機制時有真的會累到乾脆就停用算了…不然一直在找解決方法或者 setsebool 改來改去都覺得累，關掉比較一了百了。
-----
回正題上…
主要是現在在 Centos 7 上用 nginx + php-fpm ，前端在用 ckeditor + ckfinder 時，因為 ckfinder 會使用上傳，相關的動作就是建檔、建資料匣、覆寫、刪除，以前自己手邊有系統時，說真的，我是直接就把 SELinux 給關了，但後來在接案子跟在處理資安的事情時就比較會去避免「直接關掉」的作法。
後來在 google 上翻到我不太確定這樣做適不適合，但感覺至少比直接關掉 SELinux 來的好的做法就是
chcon -R -h -t httpd_sys_script_rw_t [dir]chcon：用來修改 SELinux 權限的東西
-R：指定 [dir] 以下的所有東西，包括子資料匣與其檔案
-h：等同用 --no-dereference ，意指不參照其所在的權限(應該是獨立設定，而不承接父層)
-t：等同用 --type，指定使用「httpd_sys_script_rw_t」的安全權限
---
一般在 web.service 對應的 documentRoot ，--type 應該都是 httpd_sys_content_t ，我個人猜應該是指「單純文件」，也就是只給「讀取」或「被執行」的權限，所以 php、apache、nginx 大至上一開始的都是如此的，因為「網頁」本來就是給人「看」的。
因為服務類型的網站大都會是可以讓 client 端傳上文件、資料匣，若是用來存放 client 上傳的東西的目的地只有「看」的權限，那就會出現被 SELinux 擋掉的狀況，所以這時可以把指定的資料匣改成 httpd_sys_script_rw_t 或 httpd_sys_content_rw_t 就是允許該資料匣能透過 web.service 由 client 上傳東西來儲存了。
此狀況不一定只用在 web.service ，ftp 也行，但就不能用 httpd_sys_script_rw_t 這種一看分類就是給 web.service 用的…特有的 service 還是要用特用的 type ，這樣比較安全。