[mod-security-users] Chroot, piped logging & failure to restart child process

[David F. <Da...@me...>]

Hi,

I have just found an interesting problem with a server running
mod_security with the chroot option. It leads to a total lock-up of the
server :-(

I use a piped logging process, which for the last 6 months has run without
any problem. For some reason it died (nothing to do with mod_security, and
still being investigated). Apache normally restarts these child logging
processes automatically. To quote from the manual:

'Apache will start the piped-log process when the server starts, and will
restart it if it crashes while the server is running. (This last feature is
why we can refer to this technique as "reliable piped logging".)'

However, when apache is running in a chroot with mod_security, the piped
logging binary is outside the chroot, and the running httpd can't find it.
More and more httpd processes get stuck trying to log, and eventually the
server locks up as it reaches the maximum number of child processes.

This is different to the behaviour with a more traditional chroot, in which
everything is placed inside the chroot, and then started in there. I used
to do it that way, but mod_security is much easier. I wonder if there is a
way round this problem of child process restart? Would placing a second
copy of the logging binary inside the chroot help? (This would be annoying
since it is going back to the old way of doing a chroot.)

The error log file during the failure contained:

[Sun Nov 28 16:14:18 2004] [notice] child pid 3516 exit signal Segmentation
fault (11)
piped log program '/usr/bin/mysqllog7' failed unexpectedly
unable to start piped log program '/usr/bin/mysqllog7': No such file or
directory
piped_log_maintenance: unable to respawn '/usr/bin/mysqllog7':
Unknown error 4294967295

The logging process I was using is based on the code
at http://logtomysql.sourceforge.net/ which I developed around a year ago.
It is generally reliable, but I still take it as a beta version. I have
been trying things out, and found that the failure to restart the logging
process also affects the standard "rotatelogs" program that comes with
Apache.

You can test all this by running a server with mod-security in a chroot. Do
"killall rotatelogs" and you should find that rotatelogs does not restart,
and the server quickly locks up. Without the chroot, rotatelogs restarts in
seconds, and everything continues to run.

Any ideas & help appreciated. I'll have a look at the code myself, but
don't know if I'll find a fix.

Regards,

David.


-- 
-------------------------------------------------
Email: Da...@me...
-------------------------------------------------