Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: "Insecure dependency in eval while running setgid" error
Date: Fri, 30 Mar 2007 13:11:53 +0100
Message-ID: 
 <D4E105722D20344AA9F50C624B1C24EE0B2E1893@LDNPCMEU301VEUA.INTRANET.BARCAPINT.COM>
In-Reply-To: <460C1014.9080606@aol.net>
Thread-Topic: "Insecure dependency in eval while running setgid" error
Thread-Index: AcdyNmuWYVi0+VsHSlisCDHmvgg1mQAjSdCw
From: <Sagar.Shah@barclayscapital.com>
To: <rlandrum@aol.net>
Cc: <modperl@perl.apache.org>, <WebPubRes@barclayscapital.com>

Hi Rob,


> -----Original Message-----
> From: Robert Landrum [mailto:rlandrum@aol.net]=20
> 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
>=20
> 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.
> >=20
>=20
> If you log the pid in the access file, you should be able to=20
> determine=20
> 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=20

>=20
> Also, do you have any limits on the number of requests a=20
> child process=20
> can serve?  If so, does the error appear only after apache=20
> has spawned a=20
> 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=
=20http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group d=
oes not accept legal responsibility for the contents of this message.  Al=
though the Barclays Group operates anti-virus programmes, it does not acc=
ept responsibility for any damage whatsoever that is caused by viruses be=
ing passed.  Any views or opinions presented are solely those of the auth=
or and do not necessarily represent those of the Barclays Group.  Replies=
=20to this email may be monitored by the Barclays Group for operational o=
r business reasons.
------------------------------------------------------------------------