You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Luke Kenneth Casson Leighton <lk...@samba-tng.org> on 2001/07/11 15:50:57 UTC
Re: lib/apr_signal.c
i've just this minute checked out httpd 2.0
the function apr_signal is still used in about
four places
in httpd, according to latest cvs. doing a grep
now whether any of those actually _compile_ is
another matter for more than a cursory glance.
... which brings me [doggedly] back to a question
i asked last week but did not get a response:
how is signal handling dealt with in APR?
how do i block or catch signals?
i do not want to fall foul of the report by todd sabin from
razor.bindview.com that says that 80% of programs written for
unix are vulnerable to SIGNAL attacks - especially
SIG_PIPE.
i do not pretend to understand all
of the issues but i know that they are there,
so i am raising them here
for people with more experience than i to
address them
what is APR and httpd's view with respect to signals and
signal blocking?
how is this handled?
On Tue, Jul 10, 2001 at 03:41:49PM -0700, rbb@covalent.net wrote:
>
> +1
>
> Ryan
>
> On Tue, 10 Jul 2001, David Reid wrote:
>
> > Why do we still have the apr_signal.c file in lib? We don't seem to be
> > building it anymore so can it be removed as well? If so I'll also
> > remove the Makefile.in as we're not doing anything in the lib directory
> > anymore.
> >
> > david
> >
> >
> >
> >
>
>
> _____________________________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> -----------------------------------------------------------------------------
[RANT] Re: lib/apr_signal.c
Posted by David Reid <dr...@jetnet.co.uk>.
What does this have to with lib/apr-signal.c????
Come on guys, change the subject if you're changing the topic...
david
> On Thu, Jul 12, 2001 at 12:47:13PM +0200, Sander Striker wrote:
> > [...]
> > > what i suspect is happening in subversion [correct me if i'm
> > > wrong, here!] is that they are writing their own server-code.
> >
> > You're wrong :)
>
> wha-heeey :) i like being wrong :)
>
> > subversion is going to use httpd with mod_dav as the server :)
>
> ... *enthusiastic*... omigud, i'm 25% way through mod_dav.c when
> i looked at the LOC good _grief_. okay, that's irrelevent.
>
> i get the idea.
>
> > Wondering what the framework like socketserver.py looks like.
> > Summary?
>
> SocketServer.py is basically three sets of classes [with
> specialisations of each] that you then 'mix' together to
> get the required combination for your server.
>
> set one:
>
> BaseServer. specialisations: TCPServer and UDPServer
> [i wrote a SQLTableReadingServer
> where the 'request' is the data
> _read_ from a queueing-table!]
>
> Mixin. specialisations: ForkingMixIn and ThreadingMixIn.
> [on the TODO list is a single-process
> Mixin that keeps a list of all connections
> *itself* and has to deal with them one-by-one
> with all the associated blocking and select
> problems etc. on a series of file descriptors]
>
> Handlers. basically this allows you to 'Do' things to a
> request. there are some pre-defined UDP and TCP request-handling
> classes that you still have to over-ride functions to actually
> _do_ something with the request socket, but at least it _gives_
> you a per-connection socket.
>
> the SocketServer framework basically provides a common API to
> create, handle, finish and close requests. you don't have
> to worry about how the request gets _to_ you: you only
> have to provide methods to deal _with_ the request.
>
> so you combine the above classes to get:
>
> ThreadingUDPServer
> ThreadingTCPServer
> ForkingUDPServer
> ForkingTCPServer
>
> and, with the addition of BaseServer, i created
> ForkingSQLTableReadingServer, which polls [yes, i know]
> a SQL table, locks it, reads one entry, deletes it from
> the table, unlocks the table,
> creates a handler for it, passes the entry to the
> handler, the handler Does Its Thing (in this case,
> loads from a SQL table a python script named in the
> request and runs it!)
>
> now, whilst this level of genericity is probably excessive,
> it was trivial to do, and it also provides the means to
> *transparently* add... mmmm.... SSLServer and then
> mix it in with Forking and Threading and you change *zero*
> lines of code - ssl is all done for you.
>
> redirection. loop-back testing. unix-domain-socket server.
> even a TransactNamedPipe server - whatever you can dream up.
>
>
> > It seems that the apache server framework can be extended
> > with other protocols by just adding new modules and filters.
>
> ... what if people don't want to add new modules and new filters?
>
> what if they want to go a separate route but take advantages
> of the best bits of httpd's code, and share the results?
>
> :)
>
> luke
>
Re: lib/apr_signal.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jul 12, 2001 at 12:47:13PM +0200, Sander Striker wrote:
> [...]
> > what i suspect is happening in subversion [correct me if i'm
> > wrong, here!] is that they are writing their own server-code.
>
> You're wrong :)
wha-heeey :) i like being wrong :)
> subversion is going to use httpd with mod_dav as the server :)
... *enthusiastic*... omigud, i'm 25% way through mod_dav.c when
i looked at the LOC good _grief_. okay, that's irrelevent.
i get the idea.
> Wondering what the framework like socketserver.py looks like.
> Summary?
SocketServer.py is basically three sets of classes [with
specialisations of each] that you then 'mix' together to
get the required combination for your server.
set one:
BaseServer. specialisations: TCPServer and UDPServer
[i wrote a SQLTableReadingServer
where the 'request' is the data
_read_ from a queueing-table!]
Mixin. specialisations: ForkingMixIn and ThreadingMixIn.
[on the TODO list is a single-process
Mixin that keeps a list of all connections
*itself* and has to deal with them one-by-one
with all the associated blocking and select
problems etc. on a series of file descriptors]
Handlers. basically this allows you to 'Do' things to a
request. there are some pre-defined UDP and TCP request-handling
classes that you still have to over-ride functions to actually
_do_ something with the request socket, but at least it _gives_
you a per-connection socket.
the SocketServer framework basically provides a common API to
create, handle, finish and close requests. you don't have
to worry about how the request gets _to_ you: you only
have to provide methods to deal _with_ the request.
so you combine the above classes to get:
ThreadingUDPServer
ThreadingTCPServer
ForkingUDPServer
ForkingTCPServer
and, with the addition of BaseServer, i created
ForkingSQLTableReadingServer, which polls [yes, i know]
a SQL table, locks it, reads one entry, deletes it from
the table, unlocks the table,
creates a handler for it, passes the entry to the
handler, the handler Does Its Thing (in this case,
loads from a SQL table a python script named in the
request and runs it!)
now, whilst this level of genericity is probably excessive,
it was trivial to do, and it also provides the means to
*transparently* add... mmmm.... SSLServer and then
mix it in with Forking and Threading and you change *zero*
lines of code - ssl is all done for you.
redirection. loop-back testing. unix-domain-socket server.
even a TransactNamedPipe server - whatever you can dream up.
> It seems that the apache server framework can be extended
> with other protocols by just adding new modules and filters.
... what if people don't want to add new modules and new filters?
what if they want to go a separate route but take advantages
of the best bits of httpd's code, and share the results?
:)
luke
RE: lib/apr_signal.c
Posted by Sander Striker <st...@apache.org>.
[...]
> what i suspect is happening in subversion [correct me if i'm
> wrong, here!] is that they are writing their own server-code.
You're wrong :)
subversion is going to use httpd with mod_dav as the server :)
Check out http://subversion.tigris.org/servlets/ProjectDocumentList
and http://subversion.tigris.org/project_status.html to get how
they plan on doing it.
> and httpd has some seriously excellent server-code.
Yep :)
> now, on my own, i don't have the experience to write server-code.
> not of the quality of httpd.
>
> however, what i _am_ prepared to do is to create a framework
> that mirrors that of SocketServer.py (the one in current CVS
> for the due 2.1.1 NOT the one in 2.0 NOT the one in 2.1 it
> has bugs in the ThreadingMixIn]
>
> i could use this for xvl, cliffs, all of the dcerpc daemons
> we'd like to write. etc.
>
> you could use it for httpd.
>
> subv could use it.
>
> everyone else could use it.
>
> what u think?
Wondering what the framework like socketserver.py looks like.
Summary?
It seems that the apache server framework can be extended
with other protocols by just adding new modules and filters.
But then again, I'd have to try, to see what problems we encounter
in doing so.
Sander
Re: lib/apr_signal.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 08:14:15AM -0700, rbb@covalent.net wrote:
> > 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.
okay! fantastic! *happy*. i think that's what i understood the
code to be doing.
okay.
... do you have a little time spare to help me use this code, then?
or, pointers to a FM to R?
i have [i am afraid to say :)] another idea.
i've just been helping getting SocketServer.py for Python 2.x
improved / generic [yet another base class].
SocketServer.py is basically a mix-in mechanism for UDP/TCP
with Threads/Fork/AnythingElseSuchAsSingleProcessMessaging
and the bit i did was to add UDP/TCP/AnythingYouLike.
what i suspect is happening in subversion [correct me if i'm
wrong, here!] is that they are writing their own server-code.
and httpd has some seriously excellent server-code.
now, on my own, i don't have the experience to write server-code.
not of the quality of httpd.
however, what i _am_ prepared to do is to create a framework
that mirrors that of SocketServer.py (the one in current CVS
for the due 2.1.1 NOT the one in 2.0 NOT the one in 2.1 it
has bugs in the ThreadingMixIn]
i could use this for xvl, cliffs, all of the dcerpc daemons
we'd like to write. etc.
you could use it for httpd.
subv could use it.
everyone else could use it.
what u think?
luke
Re: lib/apr_signal.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 08:14:15AM -0700, rbb@covalent.net wrote:
> > 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.
okay! fantastic! *happy*. i think that's what i understood the
code to be doing.
okay.
... do you have a little time spare to help me use this code, then?
or, pointers to a FM to R?
i have [i am afraid to say :)] another idea.
i've just been helping getting SocketServer.py for Python 2.x
improved / generic [yet another base class].
SocketServer.py is basically a mix-in mechanism for UDP/TCP
with Threads/Fork/AnythingElseSuchAsSingleProcessMessaging
and the bit i did was to add UDP/TCP/AnythingYouLike.
what i suspect is happening in subversion [correct me if i'm
wrong, here!] is that they are writing their own server-code.
and httpd has some seriously excellent server-code.
now, on my own, i don't have the experience to write server-code.
not of the quality of httpd.
however, what i _am_ prepared to do is to create a framework
that mirrors that of SocketServer.py (the one in current CVS
for the due 2.1.1 NOT the one in 2.0 NOT the one in 2.1 it
has bugs in the ThreadingMixIn]
i could use this for xvl, cliffs, all of the dcerpc daemons
we'd like to write. etc.
you could use it for httpd.
subv could use it.
everyone else could use it.
what u think?
luke
Re: lib/apr_signal.c
Posted by rb...@covalent.net.
> > 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
-----------------------------------------------------------------------------
Re: lib/apr_signal.c
Posted by rb...@covalent.net.
> > 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
-----------------------------------------------------------------------------
Re: lib/apr_signal.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 07:43:14AM -0700, rbb@covalent.net wrote:
>
> 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.
for xvl, i think... i think what i will do is simply rip all of the
signal handling / fault / blocking etc. code out. xvl doesn't
use apr_signal_thread() - it doesn't use threads [yet :)]
when this issue has been addressed [DOS attacks possible via
signals], i'll follow suit.
all best,
luke
Re: lib/apr_signal.c
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 07:43:14AM -0700, rbb@covalent.net wrote:
>
> 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.
for xvl, i think... i think what i will do is simply rip all of the
signal handling / fault / blocking etc. code out. xvl doesn't
use apr_signal_thread() - it doesn't use threads [yet :)]
when this issue has been addressed [DOS attacks possible via
signals], i'll follow suit.
all best,
luke
Re: lib/apr_signal.c
Posted by rb...@covalent.net.
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.
Ryan
On Wed, 11 Jul 2001, Luke Kenneth Casson Leighton wrote:
> i've just this minute checked out httpd 2.0
>
> the function apr_signal is still used in about
> four places
> in httpd, according to latest cvs. doing a grep
>
> now whether any of those actually _compile_ is
> another matter for more than a cursory glance.
>
> ... which brings me [doggedly] back to a question
> i asked last week but did not get a response:
>
> how is signal handling dealt with in APR?
>
> how do i block or catch signals?
>
> i do not want to fall foul of the report by todd sabin from
> razor.bindview.com that says that 80% of programs written for
> unix are vulnerable to SIGNAL attacks - especially
> SIG_PIPE.
>
>
> i do not pretend to understand all
> of the issues but i know that they are there,
> so i am raising them here
> for people with more experience than i to
> address them
>
>
> what is APR and httpd's view with respect to signals and
> signal blocking?
>
> how is this handled?
>
>
> On Tue, Jul 10, 2001 at 03:41:49PM -0700, rbb@covalent.net wrote:
> >
> > +1
> >
> > Ryan
> >
> > On Tue, 10 Jul 2001, David Reid wrote:
> >
> > > Why do we still have the apr_signal.c file in lib? We don't seem to be
> > > building it anymore so can it be removed as well? If so I'll also
> > > remove the Makefile.in as we're not doing anything in the lib directory
> > > anymore.
> > >
> > > david
> > >
> > >
> > >
> > >
> >
> >
> > _____________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > Covalent Technologies rbb@covalent.net
> > -----------------------------------------------------------------------------
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: lib/apr_signal.c
Posted by rb...@covalent.net.
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.
Ryan
On Wed, 11 Jul 2001, Luke Kenneth Casson Leighton wrote:
> i've just this minute checked out httpd 2.0
>
> the function apr_signal is still used in about
> four places
> in httpd, according to latest cvs. doing a grep
>
> now whether any of those actually _compile_ is
> another matter for more than a cursory glance.
>
> ... which brings me [doggedly] back to a question
> i asked last week but did not get a response:
>
> how is signal handling dealt with in APR?
>
> how do i block or catch signals?
>
> i do not want to fall foul of the report by todd sabin from
> razor.bindview.com that says that 80% of programs written for
> unix are vulnerable to SIGNAL attacks - especially
> SIG_PIPE.
>
>
> i do not pretend to understand all
> of the issues but i know that they are there,
> so i am raising them here
> for people with more experience than i to
> address them
>
>
> what is APR and httpd's view with respect to signals and
> signal blocking?
>
> how is this handled?
>
>
> On Tue, Jul 10, 2001 at 03:41:49PM -0700, rbb@covalent.net wrote:
> >
> > +1
> >
> > Ryan
> >
> > On Tue, 10 Jul 2001, David Reid wrote:
> >
> > > Why do we still have the apr_signal.c file in lib? We don't seem to be
> > > building it anymore so can it be removed as well? If so I'll also
> > > remove the Makefile.in as we're not doing anything in the lib directory
> > > anymore.
> > >
> > > david
> > >
> > >
> > >
> > >
> >
> >
> > _____________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > Covalent Technologies rbb@covalent.net
> > -----------------------------------------------------------------------------
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------