Hello,
I found the following behaviour in mod_perl, which is clearly
unexpected: I use an Apache that can serve both mod_perl and PHP
pages. I run it -X ; first I request the URI for this scriptlet
(under mod_perl's Apache::Registry):
#!/usr/bin/perl
$ENV{"LEAKING"}="oops";
Then I visit a PHP page that contains just phpinfo() - the LEAKING
variable is passed to it, I can see it in the HTTP_ENV_VARS.
So far, so good - a remanent environment may not be what I want, but
it certainly is not a bug. It becomes worse with a module that sets
things in the CGI namespace ($r->subprocess_env()), such as mod_ssl :
if I request the Perl scriptlet through SSL, all variables in the
subprocess_env (HTTPS, SERVER_CERTIFICATE et al., that normally show
up as HTTP_SERVER_VARS in phpinfo()) are somehow promoted as
environment variables, and become remanent in the server process
environment as shown above (i.e. they now appear as HTTP_ENV_VARS for
subsequent requests). This seems to happen at the time the first (I
didn't test more) request to an Apache::Registry script is made in the
life of an httpd : requesting phpinfo() pages beforehand doesn't
show any spurious environment data, even through SSL.
Using a debugger shows (as expected from %ENV modifications) that the
real environment (char **__environ) is modified in both scenari, so
this is not due to a bug in PHP.
I ended up writing a cleanup handler that restores %ENV to what it was
at server startup time, and everything works fine now.
Platform: RH 7.1, mod_perl 1.24_01, Apache 1.3.19, PHP 4.0.4pl1.
Sorry I cannot investigate any further by myself, because I know next
to nothing in XS and mod_perl uses it heavily. I just saw that %ENV is
tied by C code, but I hear it is related to tainting and I don't see how
this could cause the observed behaviour.
--
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>
Dominique Quatravaux <[EMAIL PROTECTED]>
