Bug 218701

Description of problem:


Version-Release number of selected component (if applicable):

logrotate-3.7.1-5.RHEL4
sysklogd-1.4.1-26_EL

How reproducible:  Very

Steps to Reproduce:

# mount -o remount,noexec /tmp
# logrotate -f /etc/logrotate.conf
  
Actual results:

Logrotate -f will output:

error: error running shared postrotate script for /var/log/messages
/var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron

lsof shows that syslogd is "hung" on the rotated logfiles:

# lsof |grep messages
syslogd    2430   root    2w      REG      253,4       505     211351
/var/log/messages.1 (deleted)

The new, empty messages file will remain empty until syslogd is manually restarted.

Expected results:

Logrotate should have some type of facility to handle security enhancements such
as mounting /tmp noexec, such as an alternative tmp directory.

Additional info:

The postrotate script seems to be the culprit, apparently logrotate writes an
actual script and then executes it?  The syslog file in /etc/logrotate.d is
stock, but here is the contents for completeness:

# cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
/var/log/boot.log /var/log/cron {
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

Additionally, it is worth noting that we have a number of ES3 systems in
production.  The above behavior is NOT reproducible on the ES3 platform, where a
noexec'ed /tmp does not seem to cause any logrotate issues.

This behavior also seems to be documented here:

http://forums.fedoraforum.org/archive/index.php/t-22359.html

Solution in above forum was to remove the noexec restriction on /tmp, which is
not desirable in our situation.