Apache and logrotate configuration

Question

Last week I found a problem on my server, because the disk usage was 100%, and I found out apache had created a huge error.log file of 60GB. I changed then the LogLevel to emerg, but after one week, it is again 1.3GB which is definitely too much.

Moreover, I have an access.log of 6MB and an other_vhosts_access.log of 167MB. So I found out that the problem could be logrotate not working. Actually the gzipped files of the logs have a very old date (23rd February).

So I tried first to change the configuration of the logrotate file for apache2, adding a max size for the file, looking now like this:

/var/log/apache2/*.log {
    weekly
    size 500M
    missingok
    rotate 20
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
                if /etc/init.d/apache2 status > /dev/null ; then \
                    /etc/init.d/apache2 reload > /dev/null; \
                fi;
    endscript
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi; \
    endscript
}

After this I tried manually to force logrotate to run a specific configuration for apache with

logrotate -f /etc/logrotate.d/apache2

and I got this error:

error: skipping "/var/log/apache2/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 "/var/log/apache2/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.
error: skipping "/var/log/apache2/other_vhosts_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.

The strange thing is that in some way it run the rotation, creating an empty error.log file, but with different permissions from the old one, and not compressing the existing error.log.

Looking at apache log directory, it looks now like this:

-rwxrwxrwx  1 root           adm            6.3M Oct 21 10:54 access.log
-rwxrwxrwx  1 root           adm             22K Feb 18  2014 access.log.1
-rwxrwxrwx  1 root           adm            7.0K Feb 16  2014 access.log.2.gz
-rwxrwxrwx  1 root           adm            4.0K Feb  9  2014 access.log.3.gz
-rw-------  1 amministratore amministratore    0 Oct 21 10:32 error.log
-rw-r--r--  1 root           root           1.3G Oct 21 10:57 error.log.1
-rwxrwxrwx  1 root           adm            167M Oct 21 10:57 other_vhosts_access.log
-rwxrwxrwx  1 root           adm            225K Feb 23  2014 other_vhosts_access.log.1
-rwxrwxrwx  1 root           adm             16K Feb 15  2014 other_vhosts_access.log.2.gz
-rwxrwxrwx  1 root           adm            3.2K Feb  8  2014 other_vhosts_access.log.3.gz

So what is the right way to proceed?

Should I change the permissions of the /var/log/apache2 directory? (which is now 777) I didn't set these permissions and I don't know if it is correct.

Or should I tell logrotate which user to use for rotation? And how?

Mohican

Dear visitors, apache configuration is off-topic on the Stack Overflow. Please visit unix.stackexchange.com , it is on-topic there. – Jaunitajaunt

@Jaunitajaunt It simply isn't true that Apache configuration questions are off topic here. There are thousands of them on Stack Overflow. See What topics can I ask about here?. It may (or may not) be more appropriate to ask some questions about specific configuration issues such as security or performance on other SE sites, but to assert that all configuration questions are off topic here is absurd. Your claim is also disingenuous since you chose to edit the question as well as telling everyone it was off topic! – Arvid

@Jaunitajaunt And if you are genuinely concerned about the validity of Apache configuration questions on Stack Overflow then raise the issue on Stack Overflow Meta for clarification.. – Arvid

Answer 1

Following the instructions from a Website, I have just changed the logrotate configuration file, adding the requested su directive as follows and now it rotates in the right way.

su <user> <group>

Mohican

Just gave you a +1. I was trouble shooting for an embarrassing length of time wondering why my anacron logrotate did not work. My log directory was own by me. logrotate needs owner to be root in this case. So I chown the log dir to root and added su root me to the logrotate config file. Thanks for posting your solution. – Ventre

Can you summarize the instructions in case that link stops working? – Computer

well, the link stopped working! i think when you specify su <user> <group> in the config file, logrotate runs as the specified user and group. ie. new files will be created with these permissions – Jennyjeno

Please try and avoid posting external links. Link now broken. Surprise, surprise.. – Baribaric

Is there any other way to solve this problem? We have a webserver with dynamically expanding vhosts and I'd prefer to not have a logrotate config for every single site, but still want to rotate their logs. If logrotate could take the current permission, it'd be fine. – Apophyge

Nope. No cigar. I'm having the same bad time as the original author, despite I added su user group in /etc/logrotate.d/apache2config file. BTW, the test conducted by logrotate, is, IMHO, ridiculous and out of scope. It says it itself: "the parent folder ... or writable by group which is not "root", which means: whatever you stick as parent folder group, it MUST be root, or I'll refuse to do my job. Why does it matter if the folder group is not root, after all? Why would all these answers asking to use su fix the issue? they won't act on the parent folder group, will they? – Homicide

Answer 2

just add su root adm to the config file:

/var/log/apache2/*.log {
    # …
    su root adm
}

Pontificate

The username and group after su has to mach the log file(s). In my case I had to add: su syslog adm – Polymerous

I don't understand why logrotate cares about this? – Gaston

The answer does not give any background WHY this is a problem and other ways to solve it (maybe the permissions are a problem!). Not cool. – Concernment

@Pete, that's not true. The user/group just needs sufficient privileges to rename/truncate the log files and to create new ones. – Cockboat

this answer assumes the user and group and can only be valid for certain use cases on certain setups. – Husband

You need this solution in /etc/logrotate.d/apache2 file. – Corrida

I wish I knew what's wrong with logrotate. It runs as root on my server. It should have no problem whatsoever to access log files that have all sorts of permissions. I wish someone could post a complete explanation of the situation. The fix is nice to know, but WHY? – Guadalupe

I'm pretty sure the reason for this is to avoid symlink-based security vulnerabilities. As far as I can tell, the code for this stems from version 3.8.2 in 2012, and the release notes for that also mention other symlink security fixes: github.com/logrotate/logrotate/blob/main/… github.com/logrotate/logrotate/commit/… – Hatchett

Answer 3

I've got "parent directory has insecure permissions" on attempt to force-rotate syslog.
Here is how I solved it:

cat /etc/logrotate.conf
    ...
    # use the syslog group by default, since this is the owning group
    # of /var/log/syslog.
    su root syslog

vim /etc/logrotate.d/rsyslog
    # Add to top:
    su root syslog

logrotate -f /etc/logrotate.d/rsyslog
    # No errors now, log is rotated.

Shallow

Answer 4

You may add a "su " in the logrotate config file

OR

change the parent directory's permissions to 755. In your case:

 chmod 755 /var/log/apache2

Jacklight

All you have done is repeat information provided in several other answers that were posted here years earlier, but without any detail or explanation. Before posting you are expected to check that you are not just repeating information in existing answers. – Arvid

Answer 5

How do all these answers address the issue reported by logrotate itself? It says: "... because parent directory has insecure permissions (It's world writable or writable by group which is not "root")."

I can't see why using su user group fixes the parent folder permissions. And it didn't on my production system (I'm admin of the latter).

This is how I fixed it, just 1 hour ago: making happy logrotate, the webapp, and continuous deployment. Note that this may not be needed if you only want to rotate apache2 logs, but if your logs are in a specific log folder, it will help.

Let's say, for this use case, that your log folder, for CD permission strategy reasons, must be owned by gitlab-runner, and that you need to preserve Apache's ability to create app log files within the same folder:

So this is the trick: make your webserver process be able to create new app log files, yet make that folder "rotatable":

1. sudo chown gitlab-runner:root
2. vi /etc/apache2/envvars
3. change Apache2 APACHE_RUN_USER:APACHE_RUN_GROUP to gitlab-runner:gitlab-runner
4. set su gitlab-runner gitlab-runner in /etc/logrotate.d/apache2
5. Restart Apache.

Well this is the only fix I found to make all these processes happy. Using su itself in logrotate config file did not do, since the parent folder group was still not root. Which I found was a ridiculous requirement.

Again, this use case is a more specific one, where the Apache logs are located in the same log folder as the app logs, in an attempt to centralise them all. I thought it could help that I outlined the folder group requirement: "root".

Homicide