Since the project logs are about to exceed 4GB in size, we want to start using file rotation . To achieve this we have decided to use logrotate
.
These are the files I have in the logs:
$ ls -lh nginx-*
-rw-rw-r-- 1 www-data root 3,8G oct 27 14:03 nginx-access.log
-rw-r--r-- 1 www-data root 30K oct 27 14:02 nginx-error.log
Since we are not using the default Nginx logs path (saved in /var/log/nginx/
), the simplest thing was to copy the current logrotate
Nginx process and change the path to point to the project logs:
$ sudo cp /etc/logrotate.d/nginx /etc/logrotate.d/gestagro
After editing the path, the file contains the following:
$ cat /etc/logrotate.d/gestagro
/home/cesar/Development/Work/gestagro/logs/nginx-*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi \
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
}
Normally these scripts should run with the daily CRON, but it is possible to force execution. This is what it throws at me:
$ sudo logrotate -f /etc/logrotate.d/gestagro
error: skipping "/home/cesar/Development/Work/gestagro/logs/nginx-access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/home/cesar/Development/Work/gestagro/logs/nginx-error.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
Taking the suggestion from logrotate
I added the directive su
at the end to indicate the user and group to use for the rotation and to match the current user and group of the files ( www-data:root
):
$ cat /etc/logrotate.d/gestagro
/home/cesar/Development/Work/gestagro/logs/nginx-*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 0640 www-data cesar
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi \
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
su www-data root
}
If I try again:
$ sudo logrotate -f /etc/logrotate.d/gestagro
error: failed to rename /home/cesar/Development/Work/gestagro/logs/nginx-access.log to /home/cesar/Development/Work/gestagro/logs/nginx-access.log.1: Permission denied
Even though I am using user www-data
and group root
it throws me the error when trying to rename the file.
This is my first time using logrotate
, what am I missing to achieve the rotation?
logrotate
it is complaining that the permissions on the path to the log file are too wide. The directory/home/cesar/Development/Work/gestagro/logs/
is writable either by everyone, or by a group other than the grouproot
.The result is that anyone who can modify that directory, or any parent directory of it, can fool by
logrotate
substituting some of the path entries/home/cesar/Development/Work/gestagro/logs/nginx-*.log
. Depending on the configuration oflogrotate
, this can be used to perform some kind of attack. For example, if the option had been usedcopytruncate
without the optionsu
, it would be trivial to create a link to/etc/passwd
, and cause it tologrotate
truncate that file.The option
su
, which allows to restrict the permissions with which itlogrotate
manipulates files, and the verification that the directory does not have too wide write permissions, were added in response to a series of vulnerabilities link in English .I can recommend three different configurations, in order of preference:
logrotate
aswww-data:adm
. The directory with the logs must be owned bywww-data:adm
(to allowwww-data
log files to be created, if they don't exist), and all directories above the root must be owned bywww-data:adm
orroot:root
.logrotate
, use thesu
, tologrotate
act temporarily aswww-data:adm
when handling nginx log files. The rest of the requirements are like the previous option. A security flaw inlogrotate
could be used to gain permissions fromroot
.logrotate
act likeroot
. The logs directory, and all directories above it up to the root must be owned byroot:root
. nginx will not be able to create log files, so they must be created before starting nginx. An oversight could cause not all nginx logs to be saved.In all cases, it is recommended to use the minimum possible permissions, which could be 0750 or even 0700 for directories, and 0640 or even 0600 for the files themselves.
In short, the full path to the files to
logrotate
be processed should have strict permissions, to prevent someone from being exploited to truncate/modify/garbage any files theylogrotate
can access, possibly leading to full privilege escalation. .