Problems with permissions for logrotate

white_gecko picture white_gecko · Jan 30, 2015 · Viewed 21.2k times · Source

I'm writing my own logrotate configuration for some web application:

/home/me/public_html/logs/*.log {
    daily
    missingok
    rotate 15
    compress
    delaycompress
    notifempty
    create 0660 me www-data
    nosharedscripts
}

But running logrotate for these files results in:

$ sudo logrotate -d -v *.log
Ignoring logfile1.log because of bad file mode.
Ignoring logfile2.log because of bad file mode.
Ignoring otherlogfile.log because of bad file mode.

Handling 0 logs
$ ls -l
-rw-rw---- 1 me www-data  893584 Jan 27 16:01 logfile1.log
-rw-rw---- 1 me www-data  395011 Jan 27 16:01 logfile2.log
-rw-rw---- 1 me www-data 4949115 Jan 27 16:01 otherlogfile.log

Is this related to the file permissions of the actual logfiles in the directory of to the permissions specified with create 0660 me www-data?

If I change the filepermissions to -rw-r----- and the create line to

create 0640 me www-data

I get

$ sudo logrotate -d -v *.log
Ignoring logfile1.log because the file owner is wrong (should be root).
Ignoring logfile2.log because the file owner is wrong (should be root).
Ignoring otherlogfile.log because the file owner is wrong (should be root).

Handling 0 logs

My system is a debian testing/jessie.

Answer

white_gecko picture white_gecko · Jan 30, 2015

Ok, stupid situation. The logrotate command has to be executed on the configuration file instead of the log file.

$ sudo logrotate -d -v /etc/logrotate.d/my-app

It seems to be important that the parent directory of the logfile is not world writable (------rw-) and not writable by any non root group (---rw----). Otherwise, you will see:

error: skipping "/home/me/public_html/logs/logfile1.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.