问题描述
从git仓库更新了别人配置好的logrotate，发现不能正常运行。手工执行报错
代码语言：javascript复制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中，就可以避免这个问题了。
代码语言：javascript复制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
