perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Sagar.S...@barclayscapital.com>
Subject RE: "Insecure dependency in eval while running setgid" error
Date Fri, 30 Mar 2007 12:11:53 GMT
Hi Rob,


> -----Original Message-----
> From: Robert Landrum [mailto:rlandrum@aol.net] 
> Sent: 29 March 2007 20:14
> To: Shah, Sagar: IT (LDN)
> Cc: modperl@perl.apache.org
> Subject: Re: "Insecure dependency in eval while running setgid" error
> 
> Sagar.Shah@barclayscapital.com wrote:
> > I'm hoping tho that if I can create a small test case under mod_perl
> > then that opens up myself/someone-on-the-list trying it with other
> > combinations of perl & mod_perl.
> > 
> 
> If you log the pid in the access file, you should be able to 
> determine 
> the serious of page hits that eventually led to the failure, maybe.

I did this yesterday along with the other debugging. Unfortunately there
doesn't seem to be a sequence of hits. The child process could have
served multiple hits to the page in question or none at all. I tested
several times and the only pattern that I could find is that the issue
never occurs the _first_ time the child process serves my page. After
that though it still appears to be random. It could be the second,
third, or nth hit that does it.

We're 

> 
> Also, do you have any limits on the number of requests a 
> child process 
> can serve?  If so, does the error appear only after apache 
> has spawned a 
> new child?

Are MaxRequestsPerChild etc. are all the defaults as this is a
relatively early mod_perl migration, only when we have a larger chunk of
our traffic being served by mod_perl will we have enough data to justify
changes.

In most of my testing I've done a graceful restart so new code is picked
up. It's pretty quick for one child process to become corrupt. However
when I first discovered the problem it will have been with child
processes that have been running for some time. Since originally the
problem was leaking out to other pages we had to implement an hourly
graceful in case something happened over night.

I think as well as trying to get a simpler test case I'm going to look
into whether the processes serving other pages also get corrupt, but
just don't blow up with an error because no eval/system/opens are
happening with the tainted data. This will be an important test because
it will hopefully show whether this is something special about the page
we see this on, or whether it's just taint going wrong in general and
this is just the first time we've seen it exposed...

We'll update the list with what this find as I hope the archives will
serve as a useful record for anyone else that hits the problem in
future.

Sagar
------------------------------------------------------------------------
For more information about Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not accept legal
responsibility for the contents of this message.  Although the Barclays Group operates anti-virus
programmes, it does not accept responsibility for any damage whatsoever that is caused by
viruses being passed.  Any views or opinions presented are solely those of the author and
do not necessarily represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.
------------------------------------------------------------------------

Mime
View raw message