From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Description of problem: Logrotate fails to start the postrotate scripts if you have your /tmp mounted with noexec - which is common on shared systems. Looking into the strace output it seems that logrotate writes a temporary shellscript into /tmp/logroate.???? and tries to execute it. I am not running selinux. Version-Release number of selected component (if applicable): logrotate-3.7.1-2 How reproducible: Always Steps to Reproduce: 1. mount /tmp with noexec option 2. debug with logrotate -f -v /etc/logrotate.conf to see the errors Actual Results: 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 Expected Results: syslog etc. should have been HUP'd Additional info: part of strace output: write(2, "running shared postrotate script"..., 33) = 33 open("/tmp/logrotate.fjmBtI", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3 fchmod(3, 0700) = 0 write(3, "#!/bin/sh\n\n", 11) = 11 write(3, "\n\t/bin/kill -HUP `cat /var/run/s"..., 78) = 78 close(3) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7ff5708) = 12786 --- SIGCHLD (Child exited) @ 0 (0) --- wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 12786 unlink("/tmp/logrotate.fjmBtI") = 0 write(2, "error: ", 7) = 7 write(2, "error running shared postrotate "..., 144) = 144
We should be using /var/run for scripts created by logrotate rather than /tmp. Logrotate also consults TMPDIR, which seems problematic to me, anyway. What about adding a configuration file directive like: scriptrundir /fu/bar with the default being '/var/run'? Comments?
Created attachment 119155 [details] Patch to add a new directive "scriptrundir", which specifies directory to use for scripts This patch adds a new directive called "scriptrundir", which lets one specify a directory for use by logrotate for the creation and running of scripts. Having this feature offers: 1) Scripts are no longer created/run out of /tmp, which is worrisome from a security perspective. 2) Users who mount /tmp with the 'noexec' option can point logrotate somewhere more secure (a directory rwx by root only, for example) for its script needs. 3) The default directory is no longer /tmp; it is now /var/run, which is probably what it should have been in the first place. Since /var/run is used for pid files, another directory (/var/exec?) might be considered for this purpose. In fact, that's what I used on my machine to test the patch.
Created attachment 119158 [details] Updated logrotate man page to include scriptrundir, fix default state file name
How do u like solution we have used in FC4? static int runScript(char * logfn, char * script) { int rc; if (debug) { message(MESS_DEBUG, "running script with arg %s: \"%s\"\n", logfn, script); return 0; } if (!fork()) { execl("/bin/sh", "sh", "-c", script, NULL); exit(1); } wait(&rc); return rc; }
I can't say without looking at more of the code. I've not taken the FC4 plunge yet. When I do, I'll look at the code then. What I proposed works great with FC3. If this bug is fixed in FC4, why isn't this bug marked as fixed in FC4?
Because there is not open any bug report for FC4, is it?
Will this be fixed in the next update for RHEL4? I'm going to create a custom package to get this resolved now, however my concern is that if another release of this package comes out without the fix, it will override my package and break logging on those systems again, so I'd like some confirmation on this before I proceed. Thanks!
Without introducing unnecessary patches to the binary, simply adding "export TMPDIR=/var/run" to /etc/cron.daily/logrotate seems to work well in RHEL-4. Kind Regards, Michael
Changing /etc/cron.daily/logrotate in RHEL4 is not a good solution as any logrotate rpm update will overwrite that file. In rpm spec file it is not marked as a config file (and it really shouldn't be). The fix mentioned in comment 4 is a better solution (essentially reverts to what logrotate used to do in pre 3.7.0 version). Any hope for scheduling this fix to go out for RHEL4U3?
Any status on a fix for this bug?
Ain't this the same problem as in bug #149270? That one is said to be fixed, so all that might be needed is backport to RHEL (the bug mentioned is filed against FC). The other option would be to implement the fixed package by hand if there's no official fixed version for REHL. (The bug #126259 leaves an impression noexec `/tmp' is not much supported...) Peter, can you comment on the current state of this?
Fix is commited in CVS
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0696.html
*** Bug 218701 has been marked as a duplicate of this bug. ***
The problem is resolved, but this patch introduce a new bug. For example I have this script in postrotate: EXT=`date +%Y%m%d -d '1 day ago'` for FILE in $1 do if [ -f $FILE.1.gz ] then mv $FILE.1.gz $FILE.$EXT.gz fi done Argument $1 is not valorized Patch from RedHat in file logrotate.c:113 - execlp(filespec, filespec, logfn, NULL); + execl("/bin/sh", "sh", "-c", script, NULL); logfn is not used.
Please see the bug #241766.