Problems with permissions for logrotate

Question

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.

score 22 · Accepted Answer · edited Oct 24 '16 at 20:38

22

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.

edited Oct 24 '16 at 20:38

user1011471

1,090
2
14
34

answered Jan 30 '15 at 12:35

white_gecko

4,808
4
55
76

Would’ve liked a `sudo chmod [numbers] [files]` here as an actual solution. Now I have to look further. – MS Berends Apr 21 '19 at 07:16
I've changed it to a wiki answer. Could you add the respective `chmod` command? – white_gecko Apr 22 '19 at 10:04
That’s the point - I don’t know octal and `chmod` well enough :( If I’ve found it out, I’ll add it. – MS Berends Apr 22 '19 at 16:59
I would assume you have to run `chown root /home/me/public_html/logs/logfile1.log` and `chmod 600 /home/me/public_html/logs/logfile1.log` following my example from above. If you could try this out, you can add it to the answer. – white_gecko Apr 25 '19 at 22:37
The thing is many systems have a upper global configuration file. So using JUST that configuration file is generally WRONG! To combat this I have a script "logrotate_one" that merges the two then does the logrotate... https://antofthy.gitlab.io/software/logrotate_one.sh.txt – anthony Jul 10 '20 at 02:59

Problems with permissions for logrotate

1 Answers1