背景介绍
我们的生产环境下有一套 TOMCAT 下运行的程序, 为了记录应用日志, 一般都使用 Log4j 来完成
环境描述
一般我们是这样设置, 程序文件 (包括 TOMCAT 自身) 使用 TOMCAT 账号作为属主运行, 同时禁止了 TOMCAT 的 BASH. 登录系统使用了统一认证, 这样每个人都有自己的账号登录系统. 为了方便开发人员登录查看日志, 日志文件的文件权限为 rw-r-r 同时也是系统默认的 umask 由于 TOMCAT 和 TOMCAT 是本地账号, 操作人员使用了统一认证方式, 理论上不属于 TOMCAT 组的账号只用于 READ 权限查看即可. 但诡异的事情发生了
现象描述
因为日志比较大, 且实时输出, 所以每天肯定要做日志轮询. 比如当天的日志为 abc.log, 那么昨天的日志就是 abc-20180201.log 这个过程是 log4j 在凌晨自动切割的.
但诡异的是每天轮询, abc.log 的文件权限变成了 rw-r----- 既 640 权限, 普通用户没有任何权限了.
-rw-r----- 1 tomcat tomcat 5472401566 Jan 14 23:59 abc-2018-01-27.log
-rw-r----- 1 tomcat tomcat 1240070383 Jan 15 11:02 abc.log
开发人员不能检查应用日志, 这是不行的
排查过程
首先检查了目录的 umask
[root@z00w00-host abc]# umask
0022
发现是正常的, 接着检查了 tomcat 的 umask, 在 / etc/profile 也没有异常, 同时想到 tomcat 不能登录, 所以这个地方的检查意义不大.
随后和开发商议, 将日志文件文件权限强行变更, 临时恢复的正常
-rw-r--r-- 1 tomcat tomcat 5472401566 Jan 14 23:59 abc-2018-01-27.log
-rw-r--r-- 1 tomcat tomcat 1240070383 Jan 15 11:02 abc.log
但是第二天, 诡异的事情发生了
-rw-r--r-- 1 tomcat tomcat 5472401566 Jan 14 23:59 abc-2018-01-14.log
-rw-r----- 1 tomcat tomcat 5472401566 Jan 15 23:59 abc-2018-01-15.log
-rw-r----- 1 tomcat tomcat 1240070383 Jan 16 11:02 abc.log
abc.log 文件和凌晨切割的文件 abc-2018-01-15.log 文件权限全部变回 640, 而强制修改的 abc-2018-01-14.log 文件属性没有改变, 由于文件切割是由 log42j 控制, 所以基本确定是 log4j 搞的鬼.
协助开发查了一下 log4j2 在 2.9 版本以上有一个 filePermissions, 可以指定文件权限. 遂通知开发修改了这个 BUG
升级程序, 重启测试后, 问题解决
关于 log42j 引发的日志文件权限的问题
来源: http://www.bubuko.com/infodetail-2484420.html