记一个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