Bug 218701 - Logrotate causes syslog to fail if /tmp is mounted noexec
Summary: Logrotate causes syslog to fail if /tmp is mounted noexec
Status: CLOSED DUPLICATE of bug 156594
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: logrotate
Version: 4.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Peter Vrabec
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-06 21:05 UTC by Matt Whitted
Modified: 2015-01-08 00:15 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-12-06 21:58:53 UTC


Attachments (Terms of Use)

Description Matt Whitted 2006-12-06 21:05:47 UTC
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.

Comment 1 Peter Vrabec 2006-12-06 21:58:53 UTC
It's going to be fixed with logrotate-3.7.1-6.RHEL4 in next update.

*** This bug has been marked as a duplicate of 156594 ***


Note You need to log in before you can comment on or make changes to this bug.