httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: lib/apr_signal.c
Date Wed, 11 Jul 2001 15:14:15 GMT
> > APR doesn't really handle signals, for a very good reason.  They are
> > incredibly non-portable, and very difficult to deal with.  Having said
> > that, there are some APR functions for dealing with signals.
> >
> > 1)  apr_signal.  Just like signal, only portable and predictable
> >
> > 2)  apr_signal_thread  puts a single thread into sigwait.  Whenever ANY
> > signal is received that thread is woken up, and a function is called.  The
> > function is passed in to the setup_signal_thread function.
> >
> > 3)  You can get a list of signals understood by the machine.  I can't
> > remember the function, but it is there.
> >
> > Most of Apache specifically tries to avoid any signals, although the
> > parent still relies on SIGWINCH, SIGTERM, and SIGHUP.  And the children
> > rely on SIGTERM and sometimes on SIGINT.
>
> okay... so... what you are saying, effectively, is that apache is
> vulnerable to a SIGPIPE DOS attack, amongst others.

It shouldn't be.  We block all signals in all processes, and only listen
for those we care about.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Mime
View raw message