Hi Charlie, > -----Original Message----- > From: Charlie Katz [mailto:[EMAIL PROTECTED] > Sent: 30 March 2007 19:00 > To: modperl@perl.apache.org > Cc: Perrin Harkins; Shah, Sagar: IT (LDN); > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Client Research Development > Subject: Re: "Insecure dependency in eval while running setgid" error > > Hi All, > > I've been following this discussion closely because I had > what seems to be the > same problem Sagar is having. > > On Friday 30 March 2007 12:19 pm, Perrin Harkins wrote: > > 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 was initially on-board with Sagar about this being a > taint-checker problem, > but Perrin's makes a pretty good point: it *is* rather > suggestive that the > insecure dependency message refers to "while running setgid" > at the same time > that the server reports GID-EGID mismatch due to a > nonsensical EGID. I > checked and found that my server displays the EGID problem as > well, so > decided to take Perrin's advice and investigate this first. > > I ran ps, which showed that the httpd processes all have > their GID matching > their EGID. Then I checked in perl by reporting the GID and > EGID from the > parent and children and found that the nonsensical EGID > appears in the > children when they are spawned (or at least in the > PerlChildInitHandler). > This seems to localize the problem to mod_perl. > > I started greping around in the mod_perl source code (I have > 2.0.2) and found > this in modperl_perl.c: > > -------------------------------------------------------------- > ------------------------------ > static void modperl_perl_ids_get(modperl_perl_ids_t *ids) > { > ids->pid = (I32)getpid(); > #ifdef MP_MAINTAIN_PPID > ids->ppid = (I32)getppid(); > #endif > #ifndef WIN32 > ids->uid = getuid(); > ids->euid = geteuid(); > ids->gid = getgid(); > ids->gid = getegid(); > -------------------------------------------------------------- > ------------------------------ > I changed that last line to > > ids->egid = getegid(); > > then rebuilt/reinstalled/restarted, and the EGID problem is gone. > > I checked the 2.0.3 source and found this already fixed there. > > > > Sagar, can you try the same thing with your server? Perhaps > the "tainting" > problem will just disappear once this bug is fixed.
Sorry for the delayed reply, I had been on leave and had asked the other members of my team to continue to look into this and feed back to the list, but as soon as they had started looking into the issue they were asked to work on something higher priority ;-) As Fred said, great catch. The initial feeling in our team was that because we're explicitly switching taint mode on all this fix will do is change the error message from "in eval while running setgid" to something else as per the if/else block in taint.c. That said given that there was quite a gap between 2.0.2 and 2.0.3 I think your suggestion is still worth trying. This or other fixes might indirectly resolve the issue and it's always best practice to try and repeat what appears to be a bug against the latest version of the software. The only reason we held off from doing this initially was that there wasn't anything in the changes file that seemed connected, but as you've shown there are other smaller changes included also. I'll report back with how I get on. Many thanks to you and everyone else that's contributed to this thread for your continuing support and suggestions. Regards Sagar =ANYTING+BELOW+THIS+LINE+WAS+ADDED+AFTER+I+HIT+SEND= ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
