Re: Life of env vars set using Apache.pm->subprocess_env

[Geoffrey Young]

Hari Bhaskaran wrote:
Hi,

Does apache clear env variables set by $r->subprocess_env()
at the end of the request? 
sort of...

Put in another way - Does
apache start with a 'clean' environment for every request?
that's a more accurate description :)

--Geoff

Life of env vars set using Apache.pm->subprocess_env

[Hari Bhaskaran]

Hi,

Does apache clear env variables set by $r->subprocess_env()
at the end of the request?  Put in another way - Does
apache start with a 'clean' environment for every request?

Long description : -

I set a bunch of variables in one the perl-handlers using
Apache request object's $r->subprocess_env(). Do 
I need to unset these variables when I am done with 
the request? (or clear them always when I begin processing)?
Assuming the same Apache thread/process is being used next time
(serving a different client) and the code takes a different path, 
would there be any problems?

Any help is appreciated.

Thank you.

--
Hari Bhaskaran

subprocess_env wont change variable set with PerlSetEnv

[Chris Allen]

I have a variable that is set with PerlSetEnv in 
my Apache config. 


PerlSetEnv SOMEVAR FOO

On some occasions my PerlTransHandler
changes this variable:


$r->subprocess_env('SOMEVAR','BAR');


This used to work fine, and my PerlHandler (HTML::Embperl) 
would see $ENV{SOMEVAR}=='BAR'



However, I have just upgraded to apache 1.3.26,
mod_perl 1.27 and added mod_ssl 2.8.10, and this
behaviour no longer works.


$r->subprocess_env('SOMEVAR','BAR');

*only* works if SOMEVAR has not previously been
defined in the server config. Otherwise it remains
unchanged.

Any ideas as to what is happening??


Many thanks,


Chris Allen.

sections and Apache->request->subprocess_env

[Tom Mornini]

I'd like to access the original Apache startup environment variables from within  sections.

Through experimentation and reading page 498 of the Eagle that I need to use Apache->Request->subprocess_env to access the original environment in order to do this, as %ENV is cleared at interpreter creation.

However, I cannot figure out how to do this in  sections! Apache->Request returns undef (reasonably so, as there is no current request)

So, the question is this: How to get the equivalent of $r->subprocess_env from within a  section?

-- 
-- Tom Mornini
-- InfoMania Printing & Prepress
--
-- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini

Re: pnotes notes and subprocess_env

[darren chamberlain]

* Rasoul Hajikhani <[EMAIL PROTECTED]> [2002-04-18 16:29]:
> I don't seem to be able to make pnotes, notes or subprocess_env work.
> I am trying to pass a value from a handler to another, and from what I
> have read in the Eagle, and cook book, the request ought to be the
> main one in order for the pnotes, ... to work. So Here is the snippet
> of my code:

I've seen situations where $r->main does not actually return the main
request instance, and code like this has worked:

  $r = $r->main until ($r->is_main);

No explanation, but I've seen it necessary in a few cases.  In the case
of main requests, it has no effect, so it's safe to include.

(darren)

-- 
Democracy is a form of government where you can say what you
think, even if you don't think.

pnotes notes and subprocess_env

[Rasoul Hajikhani]

Folks,
I don't seem to be able to make pnotes, notes or subprocess_env work. I
am trying to pass a value from a handler to another, and from what I
have read in the Eagle, and cook book, the request ought to be the main
one in order for the pnotes, ... to work. So Here is the snippet of my
code:

.
.
.
$r->pnotes("STICKY" => "hello world");
$r->custom_response(FORBIDDEN, "/secureDB/Login");
return FORBIDDEN;
.
.
.

package secureDB::Login;

sub handler
{
my $r   = shift;
$r  = ($r->is_main ? $r : $r->main);

my $object  = undef;

my $notes   = $r->pnotes("STICKY");
warn "notes = $notes\n";
#$object->{query}= $r->args ||
$r->content;
#$object->{path} = $r->uri();

#$object->{FILE} = "secureLogin.html";

#getUserInfo($object,$uid);
    makeTemplate($object,$r);  


return OK;
}
1;

Noe I have tried subprocess_env, notes, and pnotes, but none seem to
work. I have to warn you that I can not use Apache::Request->instance()
because of my Apache version.
I appreciate all the help.
Thanks in advance
-r

Re: [BUG] $r->subprocess_env() leaking to %ENV

[Dominique Quatravaux]

> Can't all these modules (your scripts, 

 The environment leak in my test case was just to make my point clear,
not a programmatic example of course

> mod_ssl, etc) just use the request object and/or Apache notes to
> communicate?  That's exactly what they're there for!

  I get it now: there is a kind of lost-update (actually, lost-delete)
problem because both mod_ssl and mod_perl try to write into the
environment, and cleanup in the wrong sequence (update 1-update
2-cleanup 1-cleanup 2). Thank you for helping me pointing it out.

> At least mod_perl can be told not to mess with the environment:
> 
> 
>   PerlSetupEnv Off
> 

  Well sure, I even tried it but I use CGI.pm from Perl 5.6 and 

CGI.pm> $meth=$ENV{'REQUEST_METHOD'} if defined($ENV{'REQUEST_METHOD'});
CGI.pm> [...]
CGI.pm> # If $meth is not of GET, POST or HEAD, assume we're being debugged 
offline.

  And there comes a funny message in my error log telling me
to enter name=value pairs on the standard input :-) 

  Your proposition, however righteous, means a lot of work for a lot
of people... Or perhaps Apache::Registry::handler should do some
tie()ing ? (yuck)

  In the meantime, I will be cutting the StdEnvVars off from mod_ssl
configuration. Thanks again !

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

Dominique Quatravaux <[EMAIL PROTECTED]>

Re: [BUG] $r->subprocess_env() leaking to %ENV

[Roger Espel Llima]

On Wed, Jul 18, 2001 at 11:41:01AM -0400, Geoffrey Young wrote:
> well, in mod_cgi land it's not that easy to access r->notes, right?  but
> there is no reason that mod_ssl and friends couldn't set both for those of
> us who can...

*and* to (please!) have a way to turn off the environment crap in
mod_ssl.

if CGI scripts can't read notes, then it should be mod_cgi's job to
turn a bunch of notes into envs, preferably after the fork and
before the exec, so the parent process' environment doesn't get
polluted.

-- 
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html

RE: [BUG] $r->subprocess_env() leaking to %ENV

[Geoffrey Young]

> -Original Message-
> From: Roger Espel Llima [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 18, 2001 11:35 AM
> To: [EMAIL PROTECTED]
> Cc: Dominique Quatravaux
> Subject: Re: [BUG] $r->subprocess_env() leaking to %ENV
> 
> 
[snip]
 
> Can't all these modules (your scripts, mod_ssl, etc) just use the
> request object and/or Apache notes to communicate?  That's exactly
> what they're there for!

well, in mod_cgi land it's not that easy to access r->notes, right?  but
there is no reason that mod_ssl and friends couldn't set both for those of
us who can...

I suggest we start lobbying :)

--Geoff

Re: [BUG] $r->subprocess_env() leaking to %ENV

[Roger Espel Llima]

Dominique Quatravaux <[EMAIL PROTECTED]> wrote:
> 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.

The whole idea of using the environemnt for communication within a
single process seems quite wrong to me.

Can't all these modules (your scripts, mod_ssl, etc) just use the
request object and/or Apache notes to communicate?  That's exactly
what they're there for!

At least mod_perl can be told not to mess with the environment:


  PerlSetupEnv Off


-- 
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html

RE: [BUG] $r->subprocess_env() leaking to %ENV

[Sheth, Niraj]

FYI

http://forum.swarthmore.edu/epigone/modperl/quajugrar/DDC7EF25B9D6D311A2
[EMAIL PROTECTED]


-Original Message-
From: Dominique Quatravaux [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 17, 2001 2:24 PM
To: [EMAIL PROTECTED]
Subject: [BUG] $r->subprocess_env() leaking to %ENV


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]>


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be privileged. 
It is intended for the addressee(s) only. Access to this E-mail by anyone else is 
unauthorized. If you are not an addressee, any disclosure or copying of the contents 
of this E-mail or any action taken (or not taken) in reliance on it is unauthorized 
and may be unlawful. If you are not an addressee, please inform the sender immediately.

[BUG] $r->subprocess_env() leaking to %ENV

[Dominique Quatravaux]

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]>

Re: subprocess_env

[Doug MacEachern]

On Thu, 8 Jun 2000, Ian Kallen wrote:

> 
> I'm using a third party module that writes a bunch of variables to the
> subprocess_env table to setup data for the request. It has us making
> repeated class method calls like this (for our usage with Mason):
> <% Blah::foo('bletch') %>
> 
> where foo is in the Blah package merely doing this:
> 
> sub foo {
> my($s) = @_;
> my($r) = Apache->request();
> return $r->subprocess_env('foo_' . $s);
> }
> 
> I'm thinking of changing the behvior to 
> <% $ENV{'foo_bletch'} %>
> but foo_bletch isn't in the %ENV hash, so I'm looking at initializing
> every request to do this:
> $r->subprocess_env->do(
>  sub { my($k,$v)=@_;
>$ENV{$k}=$v;
>  1; 
>  }
> );
> to eliminate repeated accesses of the subprocess_env table; one call
> populates %ENV and that's it.
> 
> Now, I don't want to kick off a debate on the performance problems that
> reading/writing to the environment incur; I didn't design this behavior
> I just want to make the best of it since this is what the application
> requires of us. I just need to optimize access to the environment by
> turning the dozen or so calls per request to Blah::foo to just %ENV.  
> 
> Any ideas regarding the expense of mulitple $r->subprocess_env vs.
> accessing %ENV?

%ENV will probably be faster for lookups, since subprocess_env has the
overhead of calling a perl subroutine (pp_entersub).  it's the population
of %ENV that can be expensive.  you might be better off populating a
non-magic global, such as %Env.

subprocess_env

[Ian Kallen]

I'm using a third party module that writes a bunch of variables to the
subprocess_env table to setup data for the request. It has us making
repeated class method calls like this (for our usage with Mason):
<% Blah::foo('bletch') %>

where foo is in the Blah package merely doing this:

sub foo {
my($s) = @_;
my($r) = Apache->request();
return $r->subprocess_env('foo_' . $s);
}

I'm thinking of changing the behvior to 
<% $ENV{'foo_bletch'} %>
but foo_bletch isn't in the %ENV hash, so I'm looking at initializing
every request to do this:
$r->subprocess_env->do(
 sub { my($k,$v)=@_;
   $ENV{$k}=$v;
 1; 
 }
);
to eliminate repeated accesses of the subprocess_env table; one call
populates %ENV and that's it.

Now, I don't want to kick off a debate on the performance problems that
reading/writing to the environment incur; I didn't design this behavior
I just want to make the best of it since this is what the application
requires of us. I just need to optimize access to the environment by
turning the dozen or so calls per request to Blah::foo to just %ENV.  

Any ideas regarding the expense of mulitple $r->subprocess_env vs.
accessing %ENV?

--
Salon Internet  http://www.salon.com/
  Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326