Log File Permissions caused by Log42j
Background
In our production environment, we have a set of Tomcat running programs. To record application logs, we generally use Log4j to complete them.
Environment Description
In general, we set the program file (including TOMCAT itself) to run with the TOMCAT account as the owner, and disallow tomcat bash. The logon system uses unified authentication, so that everyone has their own account to log on to the system. To facilitate developers to log on and view logs, the Log File Permission is rw-r, which is also the default umask of the system. Because TOMCAT and TOMCAT are local accounts, in theory, accounts that do not belong to the TOMCAT group are only used to view the READ permission. But something strange happened.
Symptom description
Because logs are large and output in real time, log polling is required every day. For example, the log of the day is abc. log, then the log of yesterday is the abc-20180201.log, this process is log4j automatically cut in the early morning.
However, the odd difference is that the File Permission of abc. log is changed to rw-r-640, which means that normal users do not have any permissions.
-Rw-r ----- 1 tomcat 5472401566 Jan 14 abc-2018-01-27.log
-Rw-r ----- 1 tomcat 1240070383 Jan 15 abc. log
Developers cannot check application logs.
Troubleshooting Process
First check the directory umask
[Root @ bkjia-host abc] # umask
0022
It was found that it was normal. After checking the umask of tomcat, there was no exception in the/etc/profile. At the same time, it was not significant to check the location because tomcat could not be logged on.
Afterwards, I negotiated with the developer to forcibly change the permissions of log files and temporarily restore them to normal.
-Rw-r -- 1 tomcat 5472401566 Jan 14 abc-2018-01-27.log
-Rw-r -- 1 tomcat 1240070383 Jan 15 abc. log
But the next day, something strange happened.
-Rw-r -- 1 tomcat 5472401566 Jan 14 abc-2018-01-14.log
-Rw-r ----- 1 tomcat 5472401566 Jan 15 abc-2018-01-15.log
-Rw-r ----- 1 tomcat 1240070383 Jan 16 abc. log
Abc. log Files and early morning cut file abc-2018-01-15.log file permissions all change back to 640, while the forcibly modified abc-2018-01-14.log file properties are not changed since file cutting is controlled by log42j, therefore, it is basically the ghost of log4j.
Assist developers to check that log4j2 has a filePermissions above version 2.9, which can specify the File Permission. Notified developers to modify this BUG.
Upgrade the program, restart the test, and solve the problem.
This article permanently updates link: https://www.bkjia.com/Linux/2018-03/151243.htm