httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Some Guy <teknos...@gmail.com>
Subject Re: Process lifetime and hooks to use
Date Mon, 19 Apr 2010 12:04:02 GMT
I think my understanding of the monitor hook is fine.  I can just use the
passed in pool as my context and use the userdata_set/get APIs as I
periodically fetch / update a file.  What I'll need to play with is to see
how I can set this up as a configuration parameter.  If the post_config hook
gets called in the parent process with the apr_pool_t* passed in also being
the same one that monitor gets, then that would work.

The child hooks I think are the issue when dealing with the various MPMs,
but it might not be a problem anymore since I can just use the pool passed
into child_init as the store for my lock and cache.  Is the same pool passed
in child_init accessible in the request handler via
request->server->process->pool ?

I see a lot of modules using these static variables and globals all over -
is this safe?  Aren't the modules existing in multiple process spaces?  How
does the author know which static variables are going to be safe to access
in each hook?  I guess any statics assigned in the child_init are safe to
use in the request handlers and other threads spawned in the child_init.
And for the parent process it's probably best to just use the pool?

Thanks,

SB

On Mon, Apr 19, 2010 at 1:41 AM, alin vasile <alinachegalati@yahoo.com>wrote:

> It depends what you want to do in this hook.
>
> --- On Sun, 4/18/10, Some Guy <teknosoul@gmail.com> wrote:
>
> From: Some Guy <teknosoul@gmail.com>
> Subject: Re: Process lifetime and hooks to use
> To: modules-dev@httpd.apache.org
> Date: Sunday, April 18, 2010, 5:51 PM
>
> Ah great.  I know what I should do with that.  Any insight on the
> differences in MPMs and what to watch out for?
>
> On Sun, Apr 18, 2010 at 12:22 PM, William A. Rowe Jr.
> <wrowe@rowe-clan.net>wrote:
>
> > On 4/18/2010 2:34 AM, alin vasile wrote:
> > > the monitor hook gets only a pointer to an apr_pool_t structure.
> >
> > Take a look at apr_pool_data_* API's, that should provide you all of the
> > context and persistence you need.
> >
> > You will never see anything about servers, connections or requests
> because
> > this is running in the *parent*, it is blissfully unaware of specific
> > requests
> > and is therefore immune from being hijaaked by remote code execution and
> > less
> > severe but destabilizing attacks on the request processing code itself.
> >
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message