Tamas TEVESZ <ice@???> probably said:
> reasoning: say i want to remove the setuid bit from my exim binary
> (because delivering under EXIM_UID and EXIM_GID is sufficient, and i
> don't need any root privileges anytime after the initial binding to
> port 25). in the current scenario what logrotate and friends seem to
> do is send exim a sighup, which, essentially, results in exim
> re-rexec'ing itself - and if it doesn't have setuid root, it cannot
> bind to port 25, and it just stops.
>
> having a sigusr1 signal handler that just reopens the log files would
> solve this "problem" in a nice (and i think, not too complicated) way.
I'm running one relay-only system suid exim for some time now. It's
working just fine for log rotation ...
pir@pir-to# \ps -ef | fgrep exim
exim 26605 1 0 15:53:28 ? 0:00 /usr/local/sbin/exim -qq15m -bd
pir@pir-to# full /usr/local/sbin/exim
-rwsr-xr-x 1 exim other 1971336 Jul 24 18:35 /usr/local/sbin/exim*
I don't use logrotate to rotate exim's logs, I use exicycle which doesn't
HUP exim because it doesn't need to;
(from the spec)
] An Exim delivery process opens the main log when it first needs to write to
] it, and it keeps the file open in case subsequent entries are required - for
] example, if a number of different deliveries are being done for the same
] message. However, remote SMTP deliveries can take a long time, and this means
] that the file may be kept open long after it is renamed if "exicyclog" or
] something similar is being used to rename log files on a regular basis. To
] ensure that a switch of log files is noticed as soon as possible, Exim calls
] "stat()" on the main log's name before reusing an open file, and if the file
] does not exist, or its inode has changed, the old file is closed and Exim
] tries to open the main log from scratch. Thus, an old log file may
] remain open for quite some time, but no Exim processes should write to
] it once it has been renamed.
P.
--
pir pir-sig@??? pir-sig@???
