apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/threadproc/win32 proc.c
Date Tue, 29 Jan 2002 03:50:19 GMT
On Mon, Jan 28, 2002 at 08:52:03PM -0600, William A. Rowe, Jr. wrote:
> From: "Brian Havard" <brianh@kheldar.apana.org.au>
> Sent: Monday, January 28, 2002 9:33 PM
> > On 28 Jan 2002 21:58:16 -0000, gstein@apache.org wrote:
> > >  Add a couple new command types to process creation:
> > >  
> > >      APR_PROGRAM_ENV: start the program using the caller's environment
> > >      APR_PROGRAM_PATH: search PATH for the program, use caller's env
> > Wouldn't it be simpler to just have env==NULL imply using the parent's
> > environment? That is in fact already the case in the OS/2 implementation
> > (and Win32 by the looks of it).
> + 1 ... this patch [appeared] overly complex in the first place.  
> With an env value passes that array of envvars.  Without simply passes 
> the current environment.

It wouldn't really be simpler. If somebody accidentally passes NULL for the
env and it copies the environment down... oops. Security issue. In Apache,
we've taken some pains to limit the environment passed down to children.

But it would also open up a combination that isn't possible --
APR_PROGRAM_PATH with env==[...]. In words that is, "search for the program
on PATH, and here is the environment to use." That combination isn't
available on Unix, at least.

The enumerated type gives us the ability to specify the exact combinations
that are allowed to callers.

When I went in there and saw some sort of interpretation of env==NULL, I was
pretty surprised confused. That behavior certainly was not documented in the
header file. Having a little automagic copying of the environment isn't
necessarily a good thing in the apache world. IMO, that env==NULL behavior
should be axed and the inherit of the env should be made explicit.


Greg Stein, http://www.lyra.org/

View raw message