Error skipping because parent directory has insecure permissions

Since Logrotate 3.8, which is default on Red Hat Enterprise Linux and CentOS 7, the parent permissions on your log directories play a vital role in whether or not logrotate will be able/willing to process your logs.

If your permissions allow writes by a group that isn’t root, you may see the following error when logrotate tries to run.

$ logrotate /etc/logrotate.d/something

error: skipping "/var/www/vhosts/site.tld/logs/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/www/vhosts/site.tld/logs/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.

A default logrotate config, that looks like this, can cause that problem.

$ cat /etc/logrotate.d/something

/var/www/vhosts/site.tld/logs/access.log {
  create 0640 site_user httpd
  compress
  daily
  postrotate
    /sbin/service httpd reload > /dev/null 2>/dev/null || true
  endscript
}

It has the create statement, to recreate the logs with correct ownership/permissions, but that’s not sufficient for logrotate.

To resolve this problem, and have logrotate work properly again, you also have to add the su $user $group configuration. This causes logrotate to actually su - to that user and execute all logrotate actions as that user.

$ cat /etc/logrotate.d/something

/var/www/vhosts/site.tld/logs/access.log {
  create 0640 site_user httpd
  compress
  daily
  postrotate
    /sbin/service httpd reload > /dev/null 2>/dev/null || true
  endscript
  su site_user httpd
}

By adding a su site_user httpd in the example above, the same as the create config, logrotate can process the logs again with parent directories that have group permissions that allow groups other than root to write to those directories.

From https://github.com/logrotate/logrotate:

The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size.

By default, logrotate’s rotation consists of renaming existing log files with a numerical suffix, then recreating the original empty log file. For example, /var/log/syslog.log is renamed /var/log/syslog.log.1. If /var/log/syslog.log.1 already exists from a previous rotation, it is first renamed /var/log/syslog.log.2. (The number of backlogs to keep can be configured.)

Installation

Logrotate can be installed with the logrotate package.

By default, logrotate runs daily using a systemd timer: logrotate.timer.

Configuration

The primary configuration file for logrotate which sets default parameters is /etc/logrotate.conf; additional application-specific configuration files are included from the /etc/logrotate.d directory. Values set in application-specific configuration files override those same parameters in the primary configuration file. See logrotate.conf(5) for configuration examples and a reference of available directives.

To verify if logrotate works correctly, run it in debug mode, in this mode it does nothing except producing debug output:

logrotate --debug /etc/logrotate.conf

Compressing logs

Logrotate can compress logs with a custom command like zstd.

/etc/logrotate.conf

compress
compresscmd /usr/bin/zstd
compressext .zst
compressoptions -T0 --long
uncompresscmd /usr/bin/unzstd

See logrotate.conf(5) and zstd(1) for more details.

Usage

logrotate is usually run through the systemd service: logrotate.service.

To run logrotate manually:

# logrotate /etc/logrotate.conf

To rotate a single log file:

# logrotate /etc/logrotate.d/mylog

To simulate running your configuration file (dry run):

# logrotate --debug /etc/logrotate.d/mylog

To force running rotations even when conditions are not met, run:

# logrotate -vf /etc/logrotate.d/mylog

See logrotate(8) for more details.

Troubleshooting

exim log not rotated

If you have set the olddir variable in /etc/logrotate.conf, you will get a message such as:

error: failed to rename /var/log/exim/mainlog to /var/log/old/mainlog.1: Permission denied

To fix this, add the user exim to the group log. Then change the group of the olddir, usually /var/log/old, to log instead of the default root.

Check logrotate status

Logrotate rotations are usually logged to /var/lib/logrotate.status (the -s option allows you to specify another state file):

/var/lib/logrotate.status

"/var/log/mysql/query.log" 2016-3-20-5:0:0
"/var/log/samba/samba-smbd.log" 2016-3-21-5:0:0
"/var/log/httpd/access_log" 2016-3-20-5:0:0
...

Skipping log because parent directory has insecure permission

Configure which user and which group has to job /etc/logrotate.d/job to be run with:

file-to-be-rotated {
    su user group
    rotate 4
}

See also

• Gentoo:Logrotate
• logrotate(8) manual page
• logrotate.conf(5) manual page

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх