記一個logrotate的配置文件權限問題

問題描述

從git倉庫更新了別人配置好的logrotate，發現不能正常運行。手工執行報錯

error: Ignoring syslog because of bad file mode - must be 0644 or 0444

具體看了下，確實有個配置文件，是664。手工執行chmod 修改權限後，就能夠運行了。但這個提交以前確實時有測試過的，爲何通過上傳下載後，就不行了呢？到倉庫中去，執行下chmod想修正下權限提交，發現chmod以後git卻沒檢測到有修改。趕忙google學習下。

文件權限位

先簡介下權限位。
linux文件具備權限位屬性。通常是用三個數字表示，例如755,664,644等。
三個數字分別表明，文件全部者的權限，與文件全部者同一組的用戶的權限，不與文件全部者同組的其餘用戶的權限。
具體的每一個數字，是表明了讀寫執行(rwx)三種權限。
7轉換爲二進制是0b111，即表明有讀寫執行權限。
6轉換爲二進制是0b110,表明有讀寫權限，無執行權限。
4轉換成二進制是0b100,表明有讀權限，無寫和執行權限。
ls -l 便可看到某個文件的具體權限。
chmod 可改變某個文件的權限。

git倉庫對權限位的處理

重點來了，權限位包括了讀寫執行，但git倉庫並不記錄所有權限位。
當 git config core.fileMode 爲true時，git會記錄該文件是不是可執行的。即當你chmod將文件從664改成755時，git能夠檢測到修改，你也能夠添加提交這個改動。
但git只記錄執行權限，而不記錄讀寫權限。
換句話說，644的文件和664的文件，對git來講是沒區別的。
這就是問題的緣由了。提交者本地修改完測試的時候，權限位已經改爲644，測試了logrotate沒問題才提交上去，其餘人下載下來卻變成了664，沒法正常運行。

什麼決定了下載下來的文件權限

既然git中不記錄讀寫權限，那麼爲何下載下來時664，而不是644,666,444等其餘權限呢？
答案是，跟每一個人本地設定的umask有關。
umask設置了用戶建立文件的默認權限補碼。
在控制檯輸入umask命令，能夠打印出當前的umask值。
umask=002時, 建立的文件默認爲664(666-002)，文件夾默認爲775(777-002)
umask=022時，建立的文件默認爲644(666-022)，文件夾默認爲755(777-022)

怎麼解決logrotate的這個問題

回到問題自己，大部分時候，咱們沒必要關心644和664的區別。但出現了logrotate這種必須644的狀況時，也不可能通知到每一個人，手工去chmod或者修改每臺電腦上的umask，仍是要在SDK中解決。既然git不記錄，那就要靠編譯系統了。
例如openwrt中，就已經定義了一系列的命令。在寫包的makefile時儘可能規範些，根據產物的不一樣，選用合適的INSTALL_XXX命令，安裝到rootfs中，就能夠避免這個問題了。

INSTALL_BIN:=install -m0755
INSTALL_DIR:=install -d -m0755
INSTALL_DATA:=install -m0644
INSTALL_CONF:=install -m0600

若是確實很特殊，那就特殊處理下了，手工在對應makefile中加個chmod。

參考

stackoverflow問題：git-pull-is-setting-664-instead-of-644-permissions