httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Saccoccio" <>
Subject RE: [Fwd: Re: [RFC} mod_suexec... changing the ap_hook_get_suexec_identity]
Date Thu, 08 Aug 2002 00:41:41 GMT
> I don't see how.  If I make a request that resolves to the FastCGI
> program, how is the module going to know that it isn't supposed to launch
> that program again?

The module keeps track of which programs it launches.

> > This is functionality that has been available in mod_fastcgi
> for years under
> > 1.3.
> Maybe I am mis-understanding the request.  As I read the request, you are
> looking to make the FastCGI binary be created with the SuExec
> binary.  That seems gratuitous to me, because there are more secure ways
> to do it.

I'm not sure what your saying WRT "created".

> If the request is to allow FastCGI to use SuExec, then yeah I can see the
> benefit.

That's what it does.  When a wrapper like suexec (or cgiwrap) is in use, all
FastCGI applications are started through the wrapper (just as CGI
applications are).

> The problem may be my understanding of FastCGI.  I always thought it was
> kind of like mod_cgid, except that once the program was up and running it
> stayed up.  If it launches the binaries at startup, then your change would
> be required, yes.

Yes it is kinda like mod_cgid, but there's a bit more to it.  The
applications that are spawned do remain running.

mod_fastcgi can launch applications at startup and upon request - it depends
on how its configured.

There isn't a problem with the "on request" path because I've got a
request_rec I can pass to ap_hook_get_suexec_identity().

> > If the proposal is going to cause heartburn, I can work around it by
> > requiring a user/group be specified with the directive under Apache2.
> No heartburn, just trying to understand the issues.

The existing 1.3 mod_fastcgi code makes use of the server_rec's user/group
(and has happily for years).

The API in 2.0 doesn't allow this because I don't have a request_rec during
the post_config phase.   I guess I could gen one to use in the call, but
that seems a little bit silly - especially given that the function doesn't
*really* need a request_rec.

At any rate, I've got alternatives if you think it should remain the way it
is (say to accommodate the use of the SuexecUserGroup at a finer config


View raw message