When working with log monitoring systems like Nagios, we often encounter permission issues with rotated log files. The core problem occurs when:

• Original log files have custom permissions (e.g., o+r for Nagios access)
• Logrotate creates new files with default root ownership
• Monitoring breaks until manual permission fixes are applied

By default, logrotate creates new log files with:

# Default permissions
-rw------- 1 root root

This behavior is hardcoded in most Linux distributions' syslog implementations. The permission mask (usually 0600) comes from the umask setting of the creating process.

Here are three robust approaches to solve this:

1. Using Logrotate's create Directive

Modify your logrotate configuration (typically in /etc/logrotate.d/):

/var/log/maillog {
    rotate 7
    daily
    missingok
    notifempty
    create 0640 root nagios  # Sets mode, owner, group
    sharedscripts
    postrotate
        /bin/systemctl reload rsyslog >/dev/null 2>&1 || true
    endscript
}

2. Leveraging ACLs (Alternative Approach)

For more granular control without changing file ownership:

# Set default ACLs on the log directory
setfacl -Rdm u:nagios:r /var/log

# Apply to existing files
setfacl -Rm u:nagios:r /var/log/maillog*

3. Syslog-ng Specific Configuration

If using syslog-ng, you can enforce permissions at the source:

destination d_mail {
    file("/var/log/maillog"
         owner("root")
         group("nagios")
         perm(0640)
         create_dirs(yes));
};

After implementing changes:

# Force log rotation for testing
logrotate -vf /etc/logrotate.d/yourconf

# Verify permissions
ls -l /var/log/maillog*

# Test Nagios access
sudo -u nagios head -n1 /var/log/maillog

• Check SELinux contexts if permissions don't take effect
• Verify the creating process's umask (grep -i umask /etc/init.d/rsyslog)
• Ensure Nagios is in the specified group (groups nagios)

---

When dealing with log monitoring systems like Nagios, a common challenge arises with log rotation. The default behavior in most Linux systems creates new log files with root ownership and restrictive permissions (typically 640). This becomes problematic when:

• Monitoring tools need read access
• Logs rotate frequently
• Manual permission changes don't persist across rotations

Logrotate handles log file management through configuration files typically found in /etc/logrotate.d/. Each service (like syslog or mail) has its own configuration snippet. The key directive we need is create, which controls permissions for newly created files.

For the maillog example, we would modify or create /etc/logrotate.d/syslog (or equivalent mail log config):

/var/log/maillog {
    weekly
    rotate 4
    create 0644 root nagios
    missingok
    notifempty
    delaycompress
    sharedscripts
    postrotate
        /usr/bin/systemctl kill -s HUP rsyslog.service
    endscript
}

The crucial line is create 0644 root nagios which specifies:

• Permissions: 644 (owner read+write, group/others read)
• Owner: root
• Group: nagios

For more complex scenarios, consider these methods:

1. Using ACLs (Access Control Lists):

setfacl -Rm u:nagios:r /var/log/maillog
setfacl -Rm d:u:nagios:r /var/log/

2. Post-rotation Scripts:

postrotate
    chmod 644 /var/log/maillog
    chown root:nagios /var/log/maillog
endscript

After making changes:

1. Force a log rotation: logrotate -vf /etc/logrotate.d/syslog
2. Verify permissions: ls -l /var/log/maillog
3. Check group ownership: ls -l /var/log/maillog | awk '{print $4}'

While solving the access issue, maintain security best practices:

• Never use 777 permissions
• Prefer group-based access over world-readable
• Consider dedicated monitoring groups instead of using 'nagios' directly
• Regularly audit log file permissions

For systems using journald instead of syslog, you might need to configure journald.conf with Storage=persistent and adjust SystemMaxUse= settings.