Hi Rob,
> -----Original Message----- > From: Robert Landrum [mailto:[EMAIL PROTECTED] > 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 > > [EMAIL PROTECTED] 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. ------------------------------------------------------------------------
