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