> -----Original Message----- > From: Perrin Harkins [mailto:[EMAIL PROTECTED] > Sent: 30 March 2007 17:19 > To: Shah, Sagar: IT (LDN) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > modperl@perl.apache.org; Client Research Development > Subject: Re: "Insecure dependency in eval while running setgid" error > > > On 3/30/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > The untainting itself however happens just before the error > is thrown, > > so think it's more about estabilishing in precisely which > conditions > > the m// operator loses it's ability to untaint and coming > up with the > > most trivial demonstration of that we can. > > This might be a silly question, but what makes you think this > has to do with tainting? If it was a taint problem, wouldn't > it say "Insecure dependency in eval while running with -T > switch"? It's complaining about eval while running setgid. > (I know you said you aren't running setgid, but I think you > should be trying to figure out why it thinks it's setgid, not > why something is tainted.)
I think the text of the error message is getting confused because perl thinks it's running setgid when it isn't (that's a separate and less important issue that I think a couple of people have pointed out to get me on the right track). Earlier this week I and a colleage were looking at the perl code and I think the suffix of that error message is just decided by a block of tests not by what rows the taint error. The reason why I think it's an issue with tainting is simply because: A) It's an Insecure Depdencency error B) As I saw with the debugging output that I sent to the mailing list yesterday, the time when it goes wrong is when the m/(.*)/ line doesn't untaint a piece of text which it has untainted lots of times before just fine. Surely that should be a deterministic and repeatable action. i.e. the output should always be the same if the input is. (assuming controlled conditions with the regex engine's options) It's certainly not an error with the specific code that is being evaled or anything that code is doing. I've convinced myself of that pretty reasonably. The fact that I think I haven't hit the error before is that using a piece of tainted data in most operations doesn't result in a warning, it's only certain operations of which eval is one of. On Monday we're going to see if we can repeat the problem in our other mod_perl page just by adding some debugging to that to see if the stuff we think we're successfully untainting is actually untainted every time, or only most of the time. This'll be an interesting thing to report back on.. ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
