You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Sa...@barclayscapital.com on 2007/03/26 13:44:24 UTC
"Insecure dependency in eval while running setgid" error
Hi All,
I'm getting some quite perplexing behaviour from my application under
mod_perl and so far I haven't been able to find the cause of the issue.
I'm finding that pages which load perfectly fine under mod_perl most of
the time, sometimes fail with the error "Insecure dependency in eval
while running setgid".
The really strange thing seems to be that we're not actually running our
webserver setgid, well not if my understanding is correct.
Our webserver runs on a non-privileged port, 9100, and so when it is
started up, it's started up by the same userid that it runs as for its
whole lifecycle - the user research which has a group of fliclearusers.
At no point does the webserver switch username or group. All of the
httpd processes that ps reports on are running with this user and group,
and I've even gone as far as explicitly setting group in my httpd.cfg to
be fliclearusers with no change. Dumping the values of $< and $> from a
mod_perl handler gives me the same values also.
I get this error not only from evals in my own code, but also from evals
contained in widely used Perl modules such as Template Toolkit. Here's
an example stack trace from an eval in Template::Document
---STACK-TRACE---
Insecure dependency in eval while running setgid at
/content/research/pkgs/cpan/lib/sun4-solaris/Template/Document.pm line
82.
at /content/research/pkgs/cpan/lib/sun4-solaris/Template/Document.pm
line 82
Template::Document::new('Template::Document', 'HASH(0x200edac)') called
at /content/research/pkgs/cpan/lib/sun4-solaris/Template/Provider.pm
line 904
Template::Provider::_compile('Template::Provider=HASH(0x20fef50)',
'HASH(0x203d6a8)', 'undef') called at
/content/research/pkgs/cpan/lib/sun4-solaris/Template/Provider.pm line
556
Template::Provider::_fetch_path('Template::Provider=HASH(0x20fef50)',
'Search/results.tt') called at
/content/research/pkgs/cpan/lib/sun4-solaris/Template/Provider.pm line
148
Template::Provider::fetch('Template::Provider=HASH(0x20fef50)',
'Search/results.tt', 'undef') called at
/content/research/pkgs/cpan/lib/sun4-solaris/Template/Context.pm line
139
Template::Context::template('Template::Context=HASH(0x1cdf178)',
'Search/results.tt') called at
/content/research/pkgs/cpan/lib/sun4-solaris/Template/Service.pm line 72
eval {...} called at
/content/research/pkgs/cpan/lib/sun4-solaris/Template/Service.pm line 72
Template::Service::process('Template::Service=HASH(0x1bd7e1c)',
'Search/results.tt', 'HASH(0x2114ab4)') called at
/content/research/pkgs/cpan/lib/sun4-solaris/Template.pm line 71
Template::process('Template=HASH(0x1bd7f48)', 'Search/results.tt',
'HASH(0x2114ab4)', 'SCALAR(0x21139a0)') called at
/content/res_int/cgi/research/lib/Website/Page.pm line 120
Website::Page::display('Website::User::Search=HASH(0x1cdf238)') called
at /content/res_int/cgi/research/lib/Website/User/Search.pm line 146
Website::User::Search::display('Website::User::Search=HASH(0x1cdf238)')
called at /content/res_int/cgi/research/lib/Website/Proxy.pm line 113
eval {...} called at /content/res_int/cgi/research/lib/Website/Proxy.pm
line 111
Website::Proxy::handler('Apache2::RequestRec=SCALAR(0x1cdf064)') called
at -e line 0
eval {...} called at -e line 0
---STACK-TRACE---
Line 82 of my version of Template::Document (v2.74 from Template Toolkit
v2.14 - there aren't any relevant changes in the newer Template Toolkit
releases that are relevant to this issue afaiks) is:
$block = eval $block;
And the preceding lines untaint $block completely:
# DON'T LOOK NOW! - blindly untainting can make you go blind!
$block =~ /(.*)/s;
$block = $1;
As I say I've seen this with evals in my own code as well, and I just
don't know what I'm doing to make Perl/mod_perl think it's running in a
setgid context.
My toolchain is:
Perl 5.8.6
mod_perl 2.0.2
httpd 2.2.2
The most interesting thing, as I said earlier, is that the behaviour is
not consistent. If I hit one mod_perl page many many times then
eventually I'll get the Insecure Dependency error when I hit a
completely _separate_ mod_perl page. It reminds me of the error that
stas fixed in mod_perl 1.99_17 around the checking of TAINT_PROPER, but
the error message isn't exactly the same, and as I say above I'm on a
recent mod_perl build.
Does anyone have any ideas? Is there more useful info that I can supply?
Or are you able to give me guidance on other avenues of investigation?
Unfortunately as this code is to be client facing, we can't simply turn
taint mode off.
Best Regards
Sagar R. Shah
(PAUSE ID: SRSHAH)
=ANYTHING+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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/27/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> wrote:
> Whereas in my production environment, if I access some a new mod_perl
> page again and again over the course of a few minutes I'm almost
> guaranteed for users to trigger the error which actually occurs on
> _another_ mod_perl page which has been working okay since it's migration
> many months ago.
That's fine then. If you install some additional logging to trace
requests based on PID, you can wait for the error and then go trace it
back in your logs.
> When you say 'good state' isn't it actually the job of mod_perl to reset
> the state of certain things?
We're getting into an area of total conjecture here, since I know
almost nothing about the internals of taint mode. However, mod_perl
doesn't generally try to clean up other people's messes.
> I'm going to install Devel::Symdump so that I can use the Symbol Table
> part of Apache2::Status
That doesn't sound useful to me. What you want to know is the
sequence of events.
- Perrin
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Perrin,
Thanks again for trying to help.
> The only other thing that occurs to me, and this is a reach because
> I'm way out of my expertise, is that the problem Stas fixed earlier
> had to do with some XS code not leaving things in a good state, and
> maybe some XS code in a module you use is doing that. One thing you
> could do is add enough logging to be able to examine the series of
> requests for a process which lead up to this error. Then you'd be
> able to check if it always starts after a certain page or a certain
> sequence.
I'm afraid that the problem I have is difficult to repeat even with a
forking httpd in my development environment.
Whereas in my production environment, if I access some a new mod_perl
page again and again over the course of a few minutes I'm almost
guaranteed for users to trigger the error which actually occurs on
_another_ mod_perl page which has been working okay since it's migration
many months ago.
When you say 'good state' isn't it actually the job of mod_perl to reset
the state of certain things? Don't get me wrong, I'm not saying that
mod_perl has to fix every problem under the sun between invocations of a
page/script - for example there's no way it can fix a memory leak from a
CPAN module, but still problem still seems like something is
'corrupting' the workings/state of taint mode in the Perl interpreter so
that future evals throw the error. The only way to work around this
seems to be to do a graceful restart and thus kill off the corrupted
Perl interpreter.
It would be nice if I could somehow connect to the Perl interpreter in
the httpd child process that I know is going wrong and get it to dump
out more of its internal state, but I'm not sure how to do this.
I'm going to install Devel::Symdump so that I can use the Symbol Table
part of Apache2::Status, maybe that will shed some light on the
situation, but I'm really clutching at straws now.
Can anyone explain the negative egid that I saw. Is that normal &
expected under mod_perl ?
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/27/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> wrote:
> - It wasn't possible to repeat the error I got when running under httpd
> -X (well I tried for a long time and couldn't)
I'm guessing you just didn't hit the right combination of things. Or
maybe this problem is somehow only present after forking? You could
try setting apache to run only one process, but not use -X.
The only other thing that occurs to me, and this is a reach because
I'm way out of my expertise, is that the problem Stas fixed earlier
had to do with some XS code not leaving things in a good state, and
maybe some XS code in a module you use is doing that. One thing you
could do is add enough logging to be able to examine the series of
requests for a process which lead up to this error. Then you'd be
able to check if it always starts after a certain page or a certain
sequence.
- Perrin
Re: "Insecure dependency in eval while running setgid" error
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Charlie Katz wrote:
> Hi All,
>
> I've been following this discussion closely because I had what seems to be the
> same problem Sagar is having.
> 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->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.
Great catch - this was fixed by Gozer about a year ago, and is in 2.0.3
but not in 2.0.2.
svn annotate:
68564 dougm ids->gid = getgid();
384969 gozer ids->egid = getegid();
svn log src/modules/perl/mod_perl.c
------------------------------------------------------------------------
r384969 | gozer | 2006-03-10 16:41:10 -0800 (Fri, 10 Mar 2006) | 5 lines
Fixes a small typo that would leave ids->egid
uninitialized and cause PL_egid to get corrupted
as a result.
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hello All,
> -----Original Message-----
> From: Shah, Sagar: IT (LDN)
> Sent: 17 April 2007 09:39
> To: 'Charlie Katz'; modperl@perl.apache.org
> Cc: Perrin Harkins; clint@traveljury.com; rlandrum@aol.net;
> Client Research Development
> Subject: RE: "Insecure dependency in eval while running setgid" error
>
> Hi Charlie,
>
> > -----Original Message-----
> > From: Charlie Katz [mailto:ckatz@cfa.harvard.edu]
> > Sent: 30 March 2007 19:00
> > To: modperl@perl.apache.org
> > Cc: Perrin Harkins; Shah, Sagar: IT (LDN);
> > clint@traveljury.com; rlandrum@aol.net; 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.
It's been a while and we've been hacking away at the issue so I thought I'd report back to the list now that we've finally got to the bottom of it.
Rather than upgrading to mod_perl 2.0.3 straight away we thought we'd first try and create a smaller test case by hacking away at the code we started with and taking the good old 'binary chop' approach. We eventually found that we were able to repeat the problem in a perl script outside mod_perl so I can clearly state that this problem was not caused by a mod_perl bug.
We continued to work on our test case removing all reference to our own applications code and then stripping down any CPAN modules that the code referenced. We were eventaully able to get to the following test case which implied there was some bug in perl:
---code---
#!/opt/perl586/bin/perl -T
# pragmata
use strict;
use warnings;
use utf8;
# This line of code is based upon the decalaration of the NoTaint package
# variable in Date::Manip Template::Plugin::Date does a require of
# 'Date::Manip' rather than a use. This change in the execution order does
# indeed makes a difference of whether the bug occurs or not.
# $ENV{HOME} is tainted, so the internal eval fails, and the external eval just
# hides that, so it shouldn't have any ongoing effects
eval { eval "#" . $ENV{HOME} };
# This section of code is based upon us orginally getting a data structure back
# from XML::Simple and passing its values to our Template Toolkit template that
# involved Date::Manip::UnixDate via Template::Plugin::Date. The value in the
# datastructure from XML::Simple was utf8-tagged. The lowercasing of the result
# of a pattern match comes from Date::Manip::ParseDateString.
# do an lc on a $1 captured from a match on a utf8-tagged variable
# (assigning to $throwaway just suppresses a warning)
my $d = ' ';
utf8::upgrade($d);
$d =~ /(.)/;
my $throwaway = lc $1;
# This section just demonstrates the bug occcuring once the above operations
# have somehow 'corrupted' the internal state within Perl. In our application
# it was Template::Document where we had the regex and eval occuring
# get a tainted value fromt the environment
my $home = $ENV{HOME};
$home =~ /(.*)/;
# assing $1 back to the variable the match was done on - the new value of
# $home therefore should not be tainted....
$home = $1;
# ...but it is
eval "print \"$home\\n\";";
---code---
We are currently using perl 5.8.6 and we could repeat the problem under perl 5.8.7 but not under perl 5.8.8 so it definitely seems that the underlying bug has been fixed. Hopefully this is useful information to archive on the mailing list. If someone gets similar behaviour in the future they should be able to workaround the bug with their current perl and eliminate it completely by upgrading.
I just wanted to say thanks again to everyone that's contributed to the thread. Your support gave us the courage and direction to get to the bottom of the issue.
Regards
Sagar
=ANYTING+BELOW+THIS+LINE+WAS+ADDED+AFTER+I+HIT+SEND=
------------------------------------------------------------------------
For important statutory and regulatory disclosures and 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.
Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
------------------------------------------------------------------------
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Charlie,
> -----Original Message-----
> From: Charlie Katz [mailto:ckatz@cfa.harvard.edu]
> Sent: 30 March 2007 19:00
> To: modperl@perl.apache.org
> Cc: Perrin Harkins; Shah, Sagar: IT (LDN);
> clint@traveljury.com; rlandrum@aol.net; 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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Charlie Katz <ck...@cfa.harvard.edu>.
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.
Regards,
Charlie
--
Charlie Katz
Harvard-Smithsonian Center for Astrophysics
ckatz@cfa.harvard.edu
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> -----Original Message-----
> From: Perrin Harkins [mailto:pharkins@gmail.com]
> Sent: 30 March 2007 17:19
> To: Shah, Sagar: IT (LDN)
> Cc: clint@traveljury.com; rlandrum@aol.net;
> modperl@perl.apache.org; Client Research Development
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
>
> On 3/30/07, Sagar.Shah@barclayscapital.com
> <Sa...@barclayscapital.com> 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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/30/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> 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.)
- Perrin
RE: "Insecure dependency in eval while running setgid" error
Posted by Clinton Gormley <cl...@traveljury.com>.
> I think I remember saying that so far I've only been testing after
> graceful restarts (so what I would assume u call respawned children).
Again, this may be COMPLETELY unrelated, but I've had some serious
issues with graceful restart and stop in apache 2.2 / 2.4
With graceful restarts, I get a number of errors:
(9)Bad file descriptor: apr_socket_accept: (client socket). Also, with
restarts, there is a (small) memory leak. Just messy.
With graceful stop, if I have mod_ssl loaded, and I haven't set a
graceful stop timeout, the original processes persist for ever. I only
noticed when my machine was completely swapped out.
Now what I do is
1) have a graceful stop timeout set
2) do a graceful stop
3) do a fresh start
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Clinton,
Thanks for your input :)
> -----Original Message-----
> From: Clinton Gormley [mailto:clint@traveljury.com]
> Sent: 30 March 2007 16:50
> To: Shah, Sagar: IT (LDN)
> Cc: pharkins@gmail.com; rlandrum@aol.net;
> modperl@perl.apache.org; Client Research Development
> Subject: RE: "Insecure dependency in eval while running setgid" error
>
> I may have missed your reply somewhere in the thread, but
> Robert Landrum
> asked the question about whether this happens only in
> children that have
> respawned, and I haven't seen you comment about it.
I think I remember saying that so far I've only been testing after
graceful restarts (so what I would assume u call respawned children).
> It may be worth adding a call to Apache2::ServerUtil::restart_count()
> into the debugging statement.
>
> If this does only happen on higher generation children, then
> it might be
> that some untainted variable is skipping an untainting process in a
> BEGIN block (or something like that).
>
> This is a guess, but is probably worth excluding (and easy to do so)
Indeed, we should see if the original children of the parent httpd
process suffer from this process. I'll get the guys in my team to try
this also.
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.
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.
------------------------------------------------------------------------
RE: "Insecure dependency in eval while running setgid" error
Posted by Clinton Gormley <cl...@traveljury.com>.
I may have missed your reply somewhere in the thread, but Robert Landrum
asked the question about whether this happens only in children that have
respawned, and I haven't seen you comment about it.
It may be worth adding a call to Apache2::ServerUtil::restart_count()
into the debugging statement.
If this does only happen on higher generation children, then it might be
that some untainted variable is skipping an untainting process in a
BEGIN block (or something like that).
This is a guess, but is probably worth excluding (and easy to do so)
Clint
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> -----Original Message-----
> From: Perrin Harkins [mailto:pharkins@gmail.com]
> Sent: 30 March 2007 15:38
> To: Shah, Sagar: IT (LDN)
> Cc: rlandrum@aol.net; modperl@perl.apache.org; Client
> Research Development
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> On 3/30/07, Sagar.Shah@barclayscapital.com
> <Sa...@barclayscapital.com> wrote:
> > What we found is that sometimes the problem would occur with httpd
> > processes that had served nothing other than this page and static
> > content (gifs, js files etc.) .
>
> Okay, and did you try repeating that sequence of requests to see if it
> triggers your problem?
Yes absolutely.
> > In other cases the httpd process had
> > served cgi scripts and our other mod_perl page, but I don't
> think the
> > other mod_perl page or the forked cgi's are relevant given
> that there
> > are instances where only static content has been served.
> Is that a fair
> > conclusion to make?
>
> Not really. You seem to have already decided that the problem has
> something to do with mod_perl, but there's really no evidence for that
> at this point.
I'd like nothing more for the problem to be something that I can fix on
my end rather than requires a new release of mod_perl/perl/some other
CPAN library.
I haven't decided the problem is with mod_perl, it's just that I'm
finding it more and more difficult to feel it's with my code. That's
just a feeling I'm relaying in my emails. I'm certainly no where near
having the evidence to aportion blame. The reason that it feels to me
that mod_perl might be involved is simply because there are other
documenteded behavious to do with quite valid things persisting between
calls even when the developer doesn't expect so.
> It's a complete mystery. It could be due to a problem
> with your apache compile, or an auth module you use on certain static
> pages, or a bug in a system library that apache is compiled against,
> etc.
Interesting, I'd considered perl, mod_perl, my own code and CPAN modules
to date, but not apache or any of its auth handlers... But that's
precicesly why I want to create the most simple test case I can as this
will then lend itself for testing on other people's
builds/installations. It's only then that I'll be able to rule out my
own compilation. The possibilities are getting more low level than I
initially expected.
> It's definitely worth trying to repeat the sequence of hits that
> led to the problem on a single process apache, even if the hits were
> all static files.
We did try, but each time we got nothing. I think the smallest pattern
we had was a child process that served one static file, and then this
mod_perl page twice. That pattern certainly didn't repeat. I'll take
your advice and ask my team to pick another sequence and repeat it
several times to see if they can trigger it in a consistent manner.
Having a consistnet pattern would be great, I'm just pessimistic based
on the efforts so far... Thanks for keeping that fighting spirit in me
going :)
>
> - Perrin
>
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/30/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> wrote:
> What we found is that sometimes the problem would occur with httpd
> processes that had served nothing other than this page and static
> content (gifs, js files etc.) .
Okay, and did you try repeating that sequence of requests to see if it
triggers your problem?
> In other cases the httpd process had
> served cgi scripts and our other mod_perl page, but I don't think the
> other mod_perl page or the forked cgi's are relevant given that there
> are instances where only static content has been served. Is that a fair
> conclusion to make?
Not really. You seem to have already decided that the problem has
something to do with mod_perl, but there's really no evidence for that
at this point. It's a complete mystery. It could be due to a problem
with your apache compile, or an auth module you use on certain static
pages, or a bug in a system library that apache is compiled against,
etc. It's definitely worth trying to repeat the sequence of hits that
led to the problem on a single process apache, even if the hits were
all static files.
- Perrin
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Perrin,
> -----Original Message-----
> From: Perrin Harkins [mailto:pharkins@gmail.com]
> Sent: 30 March 2007 14:27
> To: Shah, Sagar: IT (LDN)
> Cc: rlandrum@aol.net; modperl@perl.apache.org; Client
> Research Development
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> On 3/30/07, Sagar.Shah@barclayscapital.com
> <Sa...@barclayscapital.com> wrote:
> > 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.
>
> You need the sequence this child followed on ALL requests since it was
> spawned, not just the ones from one specific page.
We did do, the change we made was to the log format in the httpd.conf so
we have the pid for every single access log entry.
What we found is that sometimes the problem would occur with httpd
processes that had served nothing other than this page and static
content (gifs, js files etc.) . In other cases the httpd process had
served cgi scripts and our other mod_perl page, but I don't think the
other mod_perl page or the forked cgi's are relevant given that there
are instances where only static content has been served. Is that a fair
conclusion to make?
As well as the access pid logging and the error log debugging we trussed
the httpd, and while I'm no expert at reading truss and have very little
C knowledge I couldn't spot anything untoward going on in terms of
system calls.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/30/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> wrote:
> 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.
You need the sequence this child followed on ALL requests since it was
spawned, not just the ones from one specific page.
- Perrin
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Robert Landrum <rl...@aol.net>.
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.
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?
Rob
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Michael,
Thanks for your response. Yes, I haven't ruled out the fact their being
a problem with my perl version (5.8.6) itself, I was just weary of going
to p5p too early, I know many people hate cross posts. Perhaps I can
point a link to this thread in archive and ask the perl specific
questions there.
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.
Thanks for giving me the push of courage I probably need to approach the
p5p team.
Sagar
> -----Original Message-----
> From: Michael Peters [mailto:mpeters@plusthree.com]
> Sent: 29 March 2007 18:44
> To: Shah, Sagar: IT (LDN)
> Cc: rlandrum@aol.net; pharkins@gmail.com; modperl@perl.apache.org
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> Sagar.Shah@barclayscapital.com wrote:
>
> > Are there any other cases? How does perl handle the special
> case above,
> > is there some magical variable
> $let_regexes_have_the_untaint_power or
> > something of that order (silly long shot I know)
>
> Sounds like a question for perl5-porters.
>
> > I have to say I'm finding it harder and harder to believe
> the issue is
> > either with my own code or with the code of any of the CPAN
> modules I'm
> > using. The suggestions from some people to just turn taint
> mode off in
> > production make me wonder whether there's been enough real
> world use of
> > taint mode in mod_perl2 to give it sufficient real world testing.
>
> Or it could be taint mode + mod_perl2 + your perl version.
> But that's something
> better asked on p5p.
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Michael Peters <mp...@plusthree.com>.
Sagar.Shah@barclayscapital.com wrote:
> Are there any other cases? How does perl handle the special case above,
> is there some magical variable $let_regexes_have_the_untaint_power or
> something of that order (silly long shot I know)
Sounds like a question for perl5-porters.
> I have to say I'm finding it harder and harder to believe the issue is
> either with my own code or with the code of any of the CPAN modules I'm
> using. The suggestions from some people to just turn taint mode off in
> production make me wonder whether there's been enough real world use of
> taint mode in mod_perl2 to give it sufficient real world testing.
Or it could be taint mode + mod_perl2 + your perl version. But that's something
better asked on p5p.
--
Michael Peters
Developer
Plus Three, LP
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi All,
I'm getting closer to this now...
> -----Original Message-----
> From: Shah, Sagar: IT (LDN)
> Sent: 29 March 2007 10:07
> To: 'Robert Landrum'; 'Perrin Harkins'
> Cc: 'modperl@perl.apache.org'
> Subject: RE: "Insecure dependency in eval while running setgid" error
>
> > > You could add:
> > >
> > > warn "BLOCK: $block\n";
> > >
> > > just above the eval, which will log all the "blocks" that are
> > > being eval
> > > to figure out which one is giving you the trouble.
> >
> > That's a useful suggestion, I'll give that a try. What I'm
> > expecting to find is that the $block that causes the error is
> > identical to previous $block values which don't cause an
> > error, but this will be a good thing to actually prove.
> >
> > Thanks very much.
>
>
> My hypothesis was correct. The $block that causes the
> Insecure Dependency error to be thrown is identical to
> previous calls to that URL.
>
> Here's what $block contains:
>
> [snip]
>
> Can anyone spot something that would cause this to throw a
> taint error (remember the $block string itself has been
> untainted, altho I think I'll add some extra debugging to
> confirm this as well).
I addded two pieces of extra debugging. One to confirm that the $block
value was always tainted before the regular expression /(.*)/ was
applied and another to confirm whether or not it was tainted after the
regular expression was applied. I was able to clearly prove that the
code works as expected (value is tained before the regex and value is
untainted after the assignemnt/before the eval) in the general case,
but not occasionally:
==logs extract, sniped for other pids==
The Block I'm just about to untaint in pid 11852 is initally tainted
The Block I'm just about to eval in pid 11852 is not tainted
The Block I'm just about to untaint in pid 11852 is initally tainted
The Block I'm just about to eval in pid 11852 is not tainted
The Block I'm just about to untaint in pid 11852 is initally tainted
The Block I'm just about to eval in pid 11852 is tainted
==logs extract, sniped for other pids==
It doesn't seem to be related to the parameters sent to the script at
all, or the number of times the script hits the infected page. What I
think I've now clearly proven is that after some point in time the perl
interpreter loses it's ability to untaint variables via regular
expressions (or to be specific the values of variables containting regex
captured text is still tainted). As soon as this happens once the
problem remains for the length of that child httpd process's life.
Can anyone think of why this might happen?
I know that Perl has a special case: if you 'use locale;' then
character classes such as \w lose their ability to untaint because the
local locale on the box is considered untrusted. I don't think this case
applies here because a) The template toolkit developer hasn't used a
character class b) use locale is not in play (I've gone as far as
putting no locale in Template::Document).
Are there any other cases? How does perl handle the special case above,
is there some magical variable $let_regexes_have_the_untaint_power or
something of that order (silly long shot I know)
I have to say I'm finding it harder and harder to believe the issue is
either with my own code or with the code of any of the CPAN modules I'm
using. The suggestions from some people to just turn taint mode off in
production make me wonder whether there's been enough real world use of
taint mode in mod_perl2 to give it sufficient real world testing.
I guess the next step is for me to try and produce a simpler test case,
one that cuts out the functionality of this page itself and just shows a
script that just does a regex untaint failing after repeated calls. As I
have other taint related code that's been running under mod_perl fine,
it's still unclear why it's this code that I'm first seeing the problem
with.
> Once a particular process produces this Insecure Dependency,
> it seems that any future calls to that same process will also
> produce the error. So again, it definitely looks like the
> process is being corrupted in some way....
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> > You could add:
> >
> > warn "BLOCK: $block\n";
> >
> > just above the eval, which will log all the "blocks" that are
> > being eval
> > to figure out which one is giving you the trouble.
>
> That's a useful suggestion, I'll give that a try. What I'm
> expecting to find is that the $block that causes the error is
> identical to previous $block values which don't cause an
> error, but this will be a good thing to actually prove.
>
> Thanks very much.
My hypothesis was correct. The $block that causes the Insecure
Dependency error to be thrown is identical to previous calls to that
URL.
Here's what $block contains:
====
sub {
my $context = shift || die "template sub called without context\n";
my $stash = $context->stash;
my $output = '';
my $error;
eval { BLOCK: {
#line 1 "/content/research/data/template/tt/User/Search/results.tt"
# USE
$stash->set('localsite',
$context->plugin('LocalSite'));
$output .= "\n";
#line 2 "/content/research/data/template/tt/User/Search/results.tt"
# USE
$stash->set('date',
$context->plugin('date'));
$output .= "\n";
#line 3 "/content/research/data/template/tt/User/Search/results.tt"
# USE
$stash->set('CGI',
$context->plugin('CGI'));
$output .= "\n";
#line 60 "/content/research/data/template/tt/User/Search/results.tt"
if ($stash->get('results')) {
#line 4 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('manip', $stash->get(['date', 0, 'manip', 0]));
#line 4 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('count', $stash->get(['CGI', 0, 'param', [ 'resultstart' ]])
|| 1);
$output .= " \n <input type=\"hidden\" name=\"resultscount\"
id=\"resultscount\" value=\"";
#line 9 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('hits');
$output .= "\">\n";
#line 21 "/content/research/data/template/tt/User/Search/results.tt"
if ($stash->get('count') eq 1) {
$output .= "\n <table width=\"100%\" border=\"0\"
cellspacing=\"0\" cellpadding=\"0\" class=\"headerBarA\">\n
<tr>\n <td class=\"headers\" width=\"5\" valign=\"top\"
align=\"right\"><img src=\"";
#line 15 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get(['localsite', 0, 'imagesRoot', 0]);
$output .= "/spacer.gif\" width=\"5\" height=\"20\"></td>\n
<td class=\"headers\" valign=\"middle\" width=\"595\">\n ";
#line 17 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('hits');
$output .= " matches across ";
#line 17 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('collection_total');
$output .= " articles\n </td>\n </tr>\n
</table>\n";
}
$output .= "\n <table width=\"100%\" border=\"0\"
cellspacing=\"0\" cellpadding=\"2\" id=\"results_table\">\n
<tr><td colspan=\"2\"><img src=\"";
#line 25 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get(['localsite', 0, 'imagesRoot', 0]);
$output .= "/spacer.gif\" width=\"1\" height=\"1\"></td></tr>\n";
#line 60 "/content/research/data/template/tt/User/Search/results.tt"
if (($stash->get('hits') > 0)) {
#line 50 "/content/research/data/template/tt/User/Search/results.tt"
# FOREACH
do {
my ($value, $error, $oldloop);
my $list = $stash->get('results');
unless (UNIVERSAL::isa($list, 'Template::Iterator')) {
$list = Template::Config->iterator($list)
|| die $Template::Config::ERROR, "\n";
}
($value, $error) = $list->get_first();
$stash = $context->localise();
$stash->set('loop', $list);
eval {
LOOP: while (! $error) {
$stash->get(['import', [$value]]) if ref $value eq 'HASH';
#line 0 "/content/research/data/template/tt/User/Search/results.tt"
if ($stash->get('HasAttachments')) {
#line 0 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('link', ($stash->get(['localsite', 0, 'documentRoot', 0]) .
"/serve/" . $stash->get('VdkVgwKey')));
#line 0 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('attachment_icon', ("<img src=\"" .
$stash->get(['localsite', 0, 'imagesRoot', 0]) . "/icon_paperclip.gif\"
width=\"10\" height=\"10\" border=\"0\" title=\"attachment\"> "));
}
else {
#line 0 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('link', ($stash->get(['localsite', 0, 'documentRoot', 0]) .
"/show/" . $stash->get('VdkVgwKey')));
#line 0 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('attachment_icon', '');
}
#line 39 "/content/research/data/template/tt/User/Search/results.tt"
if (($stash->get('count') > 1)) {
$output .= "\n <tr><td colspan=\"2\"><hr size=\"1\"
width=\"100%\" bgcolor=\"#CCCCCC\"></td></tr>\n";
}
$output .= "\n <tr>\n <td valign=\"top\"
class=\"content\"><b><font color=\"#336699\">";
#line 43 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('count');
$output .= ".</font></b></td>\n <td valign=\"top\">\n
<div>";
#line 45 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('attachment_icon');
$output .= "<a href=\"";
#line 45 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('link');
$output .= "\" target=\"_new";
#line 45 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('count');
$output .= "\"><b>";
#line 45 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get(['manip', 0, 'UnixDate', [
$stash->get('VisibilityDate'), '%d %b %Y' ]]);
$output .= ": ";
#line 45 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('Headline');
$output .= "</b></a></div>\n <div class=\"contentBlack\"
style=\"padding-top:4px; padding-bottom:4px;\">";
#line 46 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('VdkPBSummary');
$output .= "</div>\n <div align=\"right\"><a href=\"";
#line 47 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get(['localsite', 0, 'cgiRoot', 0]);
$output .= "/public/showCategory.pl?category=";
#line 47 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('CategoryId');
$output .= "\"
target=\"_new\"><b>View similar articles</b></a> &n
bsp;<a href=\"";
#line 47 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get(['localsite', 0, 'documentRoot', 0]);
$output .= "/profadd/";
#line 47 "/content/research/data/template/tt/User/Search/results.tt"
$output .= $stash->get('CategoryId');
$output .= "\"
target=\"_new\"><b>Subscribe to category</b></a></div>\n
</td>\n </tr>\n";
#line 50 "/content/research/data/template/tt/User/Search/results.tt"
$stash->set('count', $stash->get('count') + 1);;
($value, $error) = $list->get_next();
}
};
$stash = $context->delocalise();
die $@ if $@;
$error = 0 if $error && $error eq Template::Constants::STATUS_DONE;
die $error if $error;
};
}
else {
$output .= "\n <tr>\n <td class=\"tabledata\"
colspan=\"2\">\n No articles match your search
specification.\n </td>\n </tr>\n";
}
}
$output .= "\n </table>\n\n";
} };
if ($@) {
$error = $context->catch($@, \$output);
die $error unless $error->type eq 'return';
}
return $output;
}
====
Can anyone spot something that would cause this to throw a taint error
(remember the $block string itself has been untainted, altho I think
I'll add some extra debugging to confirm this as well).
Once a particular process produces this Insecure Dependency, it seems
that any future calls to that same process will also produce the error.
So again, it definitely looks like the process is being corrupted in
some way....
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Rob,
Thanks for your response.
> -----Original Message-----
> From: Robert Landrum [mailto:rlandrum@aol.net]
> Sent: 28 March 2007 18:06
> To: Perrin Harkins
> Cc: Shah, Sagar: IT (LDN); modperl@perl.apache.org
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> Perrin Harkins wrote:
> > On 3/28/07, Sagar.Shah@barclayscapital.com
> > <Sa...@barclayscapital.com> wrote:
> >> > Keep taint mode on in dev, so you can identify your issues in
> >> > development, then turn in off in prod.
> >>
> >> Is that actually the generally recommended approach?
> >
> > It's hard to know for sure that you've tried every code path in dev,
> > even if you do use coverage analysis.
> >
>
> Here's the bit that's causing the issue...
>
> # DON'T LOOK NOW! - blindly untainting can make you go blind!
> $block =~ /(.*)/s;
> $block = $1;
>
> $block = eval $block;
>
> That's a little bit nasty, but perfectly valid. $block is
> coming from a
> document containing some sort of code, I think. I didn't dig
> too deep.
Yup, included that fragment in my original mail. That should be
untainting everything, although I guess it's only untainting the "string
of the code" and the code could throw a taint error itself when eval
runs it. I only have three templates and these are loaded the vast
majority of the time without causing any issue at all.... Also the
fact that I've seen the same error from other evals ni the code such as
eval "use $module;" it still makes me think it's got more to do with
the interpreter state between calls.
> You could add:
>
> warn "BLOCK: $block\n";
>
> just above the eval, which will log all the "blocks" that are
> being eval
> to figure out which one is giving you the trouble.
That's a useful suggestion, I'll give that a try. What I'm expecting to
find is that the $block that causes the error is identical to previous
$block values which don't cause an error, but this will be a good thing
to actually prove.
Thanks very much.
>
> Rob
>
>
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Robert Landrum <rl...@aol.net>.
Perrin Harkins wrote:
> On 3/28/07, Sagar.Shah@barclayscapital.com
> <Sa...@barclayscapital.com> wrote:
>> > Keep taint mode on in dev, so you can identify your issues in
>> > development, then turn in off in prod.
>>
>> Is that actually the generally recommended approach?
>
> It's hard to know for sure that you've tried every code path in dev,
> even if you do use coverage analysis.
>
Here's the bit that's causing the issue...
# DON'T LOOK NOW! - blindly untainting can make you go blind!
$block =~ /(.*)/s;
$block = $1;
$block = eval $block;
That's a little bit nasty, but perfectly valid. $block is coming from a
document containing some sort of code, I think. I didn't dig too deep.
You could add:
warn "BLOCK: $block\n";
just above the eval, which will log all the "blocks" that are being eval
to figure out which one is giving you the trouble.
Rob
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> -----Original Message-----
> From: Perrin Harkins [mailto:pharkins@gmail.com]
> Sent: 28 March 2007 17:18
> To: Shah, Sagar: IT (LDN)
> Cc: modperl@perl.apache.org
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> On 3/28/07, Sagar.Shah@barclayscapital.com
> <Sa...@barclayscapital.com> wrote:
> > > Keep taint mode on in dev, so you can identify your issues in
> > > development, then turn in off in prod.
> >
> > Is that actually the generally recommended approach?
>
> It's hard to know for sure that you've tried every code path in dev,
> even if you do use coverage analysis.
>
> I think the reality though is that hardly anyone uses taint mode.
> It's a lot of work.
Well it requires you to think about your inputs and write/re-use
suitable regexes, but apart from that I think the benefits outweight the
costs. I've been this taint mode in this particular system for three
years and this is the first time I've run into a crazy issue like this.
> > I know there are some people that argue that warnings should also be
> > turned off in prod
>
> Those people are nuts. Warnings give very valuable feedback about
> unforeseen errors in prod, and the only risk is a larger log file.
>
> - Perrin
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/28/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> wrote:
> > Keep taint mode on in dev, so you can identify your issues in
> > development, then turn in off in prod.
>
> Is that actually the generally recommended approach?
It's hard to know for sure that you've tried every code path in dev,
even if you do use coverage analysis.
I think the reality though is that hardly anyone uses taint mode.
It's a lot of work.
> I know there are some people that argue that warnings should also be
> turned off in prod
Those people are nuts. Warnings give very valuable feedback about
unforeseen errors in prod, and the only risk is a larger log file.
- Perrin
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> -----Original Message-----
> From: Robert Landrum [mailto:rlandrum@aol.net]
> Sent: 28 March 2007 16:30
> To: Shah, Sagar: IT (LDN)
> Cc: fred@redhotpenguin.com; modperl@perl.apache.org
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> Sagar.Shah@barclayscapital.com wrote:
> > Unfortunately turning taint mode off isn't an option for me. My
> > application is client facing and so we want to continue to
> make use of
> > the security mechanism that taint mode gives us.
> >
>
> Keep taint mode on in dev, so you can identify your issues in
> development, then turn in off in prod.
Is that actually the generally recommended approach?
I know there are some people that argue that warnings should also be
turned off in prod, but I've always thought that having -wT in prod was
the best way to ensure you don't get any security holes.
I know it could be argued that the test rig in dev should pick up any
issues, but when you're working on a public web based system you can't
forsee every crazy and not-so-crazy permutation of input you end up
getting.
I wouldn't mind disabling taint as a temporary solution, if we found
that the issue I'm having was a bug in mod_perl/some_module and it was
just a case of accepting a fix, but I feel very nervous about giving up
on taint mode in prod forever as this is something that I sell as an
advantage of Perl to our security department when I argue why our
application doesn't need to fit the standard company architectures that
are designed with Java and .NET apps in mind.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Robert Landrum <rl...@aol.net>.
Sagar.Shah@barclayscapital.com wrote:
> Unfortunately turning taint mode off isn't an option for me. My
> application is client facing and so we want to continue to make use of
> the security mechanism that taint mode gives us.
>
Keep taint mode on in dev, so you can identify your issues in
development, then turn in off in prod.
Rob
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Rob,
Thanks for your response.
> See if fgrep -r 'perl' * | grep '-T' in you modules directory returns
> anything. Also make sure PerlTaintCheck On isn't in your
> config. Also,
> a lot of times I'll put -T in the shebang line of my handler.pl or
> startup.pl, which will enable Taint checking.
Unfortunately turning taint mode off isn't an option for me. My
application is client facing and so we want to continue to make use of
the security mechanism that taint mode gives us.
Regards
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Robert Landrum <rl...@aol.net>.
Fred Moyer wrote:
> Or maybe this is a bug in getegid where it's not clearing a previous
> memory state. What platform is this on?
>
sun4-solaris
His first post had a list of modules in a stack trace, which is where I
grabbed that.
I googled, but didn't find anything relevant. :(
See if fgrep -r 'perl' * | grep '-T' in you modules directory returns
anything. Also make sure PerlTaintCheck On isn't in your config. Also,
a lot of times I'll put -T in the shebang line of my handler.pl or
startup.pl, which will enable Taint checking.
Rob
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Fred,
Thanks for your response
> -----Original Message-----
> From: Fred Moyer [mailto:fred@redhotpenguin.com]
> Sent: 27 March 2007 17:30
> 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 changed a mod_perl page to actually print out gid and
> egid. Both $(
> > and $) are actually a space seperated list of group ids,
> what I found is
> > that under mod_perl I get:
> >
> > $GID 451 451
> > $EGID -19253340 451
> >
> > 451 is fliclearusers, the primary group of my account. I
> have no idea
> > where this negative number comes from. Certainly running
> perl -e 'print
> > $)' doesn't return it.
> >
> > So I'm again at the stage where I'm thinking is is an issue with the
> > state of the perl/mod_perl interpreter rather than my code or a CPAN
> > module's code.
> >
> > Can anyone shed any light on that negative egid value?
> (/usr/bin/ps
> > certainly doesn't show such a value)
>
> My guess as to why $EGID is negative is that it's exceeding 2**32/2 -
> it's signed int according to the source (mp1). The only reason I'm
> guessing here is that I had to fix a sprintf bug not too long
> ago where
> our interpolated object ids were returning negative numbers
> because we
> exceeded 2 billion transactions in our system.
>
> src/modules/perl/perl_util.c
>
> 668 void mod_perl_init_ids(void) /* $$, $>, $), etc */
> 669 {
> 670 if(set_ids++) return;
> 671 sv_setiv(GvSV(gv_fetchpv("$", TRUE, SVt_PV)), (I32)getpid());
> 672 #ifndef WIN32
> 673 uid = (int)getuid();
> 674 euid = (int)geteuid();
> 675 gid = (int)getgid();
> 676 egid = (int)getegid();
> 677 MP_TRACE_g(fprintf(stderr,
> 678 "perl_init_ids: uid=%d, euid=%d, gid=%d, egid=%d\n",
> 679 uid, euid, gid, egid));
> 680 #endif
> 681 }
Thanks that helps, but I'm still not clear how my gid changes. When
trussing my webserver (and all the forked children) I couldn't find any
setegid or getegid calls at all... (although I needed to do a graceful
restart to get the truss process to pickup the children, so I guess the
parent could have done something prior to this - worth me checking
out....)
> > What I found was if I changed my Website::Proxy module to load all
> > modules on webserver startup (i.e. in it's own BEGIN block) rather
> > than on demand then the eval errors there stopped. This
> seems to imply
> > that the interpreter is getting into a confused state after some
> > continued use.
>
> Or maybe this is a bug in getegid where it's not clearing a previous
> memory state. What platform is this on?
Solaris 8
> Question - are you preloading these modules in startup.pl or
> something
> similar? It sounds like you aren't from the snippet above.
I think what I'm doing is the equivalent. I do a PerlModule
Website::Proxy in my httpd.conf which causes the module to be loaded,
and thus via its BEGIN block the loading of all other modules. I'm
reasonably certain it's working correctly because when putting in some
debugging I've seen that the BEGIN block is not executed once per child
process.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Sagar.Shah@barclayscapital.com wrote:
> - I changed a mod_perl page to actually print out gid and egid. Both $(
> and $) are actually a space seperated list of group ids, what I found is
> that under mod_perl I get:
>
> $GID 451 451
> $EGID -19253340 451
>
> 451 is fliclearusers, the primary group of my account. I have no idea
> where this negative number comes from. Certainly running perl -e 'print
> $)' doesn't return it.
>
> So I'm again at the stage where I'm thinking is is an issue with the
> state of the perl/mod_perl interpreter rather than my code or a CPAN
> module's code.
>
> Can anyone shed any light on that negative egid value? (/usr/bin/ps
> certainly doesn't show such a value)
My guess as to why $EGID is negative is that it's exceeding 2**32/2 -
it's signed int according to the source (mp1). The only reason I'm
guessing here is that I had to fix a sprintf bug not too long ago where
our interpolated object ids were returning negative numbers because we
exceeded 2 billion transactions in our system.
src/modules/perl/perl_util.c
668 void mod_perl_init_ids(void) /* $$, $>, $), etc */
669 {
670 if(set_ids++) return;
671 sv_setiv(GvSV(gv_fetchpv("$", TRUE, SVt_PV)), (I32)getpid());
672 #ifndef WIN32
673 uid = (int)getuid();
674 euid = (int)geteuid();
675 gid = (int)getgid();
676 egid = (int)getegid();
677 MP_TRACE_g(fprintf(stderr,
678 "perl_init_ids: uid=%d, euid=%d, gid=%d, egid=%d\n",
679 uid, euid, gid, egid));
680 #endif
681 }
> What I found was if I changed my Website::Proxy module to load all
> modules on webserver startup (i.e. in it's own BEGIN block) rather
> than on demand then the eval errors there stopped. This seems to imply
> that the interpreter is getting into a confused state after some
> continued use.
Or maybe this is a bug in getegid where it's not clearing a previous
memory state. What platform is this on?
Question - are you preloading these modules in startup.pl or something
similar? It sounds like you aren't from the snippet above.
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> -----Original Message-----
> From: Shah, Sagar: IT (LDN)
> Sent: 26 March 2007 17:30
> To: 'Perrin Harkins'
> Cc: 'modperl@perl.apache.org'
> Subject: RE: "Insecure dependency in eval while running setgid" error
>
>
> > > Alternatively, if you can run your server in
> single-process mode and
> > > come up with a repeatable series of steps that cause the
> error, you
> > > can work back from the point where you saw the error
> until you find
> > > the offending code.
> >
> >
> > Yes, httpd -X is a good idea. I should have thought of that
> > before. I'll give that a go and report back to the list.
>
> Our site only has three mod_perl pages, and I've cycled
> through all of them with the webserver, trying to model
> behaviour that goes through the different execution paths, in
> single process mode but still been unable to repeat the
> error. I'll keep on trying but I'm not sure if the issue is a
> badly behaved CPAN module. I've been through my
> $HOME/.cpan/build directory for modules I've installed in the
> last few months, again I couldn't see any setgid references
> even though I was now searching through .xs files also.
>
>
> I should point out that sometimes in the past I've seen the
> error in our Website::Proxy module. This module is simply a
> url mapping module which would take a url like
> /research/user/search and map that to the module
> Website::User::Search and it would do a eval "use $module;"
> (where $module is untained) before calling the constructor
> and delegating construction of the page. I saw the same error
> at that eval statement also. Again this was sporadic, but
> here I would have been simply compiling the code of modules
> rather than running them (save for code in BEGIN blocks etc.).
>
> What I found was if I changed my Website::Proxy module to
> load all modules on webserver startup (i.e. in it's own BEGIN
> block) rather than on demand then the eval errors there
> stopped. This seems to imply that the interpreter is getting
> into a confused state after some continued use.
>
> Does anyone have any other suggestions?
Hi All,
I'm replying to my own post twice, so as you can guess I'm getting
pretty desperate ;-)
I've continued investigating this issue. Interesting facts:
- It wasn't possible to repeat the error I got when running under httpd
-X (well I tried for a long time and couldn't)
- I tried trussing the httpd and it's child processes, no setgid or
setegid calls were made. The only gid related calls were getgid (which
returned the correct group id) and getpgid (which I was expecting to
return the parent process's gid but truss showed it to simply return the
parent's pid...)
- I changed a mod_perl page to actually print out gid and egid. Both $(
and $) are actually a space seperated list of group ids, what I found is
that under mod_perl I get:
$GID 451 451
$EGID -19253340 451
451 is fliclearusers, the primary group of my account. I have no idea
where this negative number comes from. Certainly running perl -e 'print
$)' doesn't return it.
So I'm again at the stage where I'm thinking is is an issue with the
state of the perl/mod_perl interpreter rather than my code or a CPAN
module's code.
Can anyone shed any light on that negative egid value? (/usr/bin/ps
certainly doesn't show such a value)
Regards
Sagar
=ANYTHING+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.
------------------------------------------------------------------------
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
> > Alternatively, if you can run your server in single-process mode and
> > come up with a repeatable series of steps that cause the error, you
> > can work back from the point where you saw the error until you find
> > the offending code.
>
>
> Yes, httpd -X is a good idea. I should have thought of that
> before. I'll give that a go and report back to the list.
Our site only has three mod_perl pages, and I've cycled through all of
them with the webserver, trying to model behaviour that goes through the
different execution paths, in single process mode but still been unable
to repeat the error. I'll keep on trying but I'm not sure if the issue
is a badly behaved CPAN module. I've been through my $HOME/.cpan/build
directory for modules I've installed in the last few months, again I
couldn't see any setgid references even though I was now searching
through .xs files also.
I should point out that sometimes in the past I've seen the error in our
Website::Proxy module. This module is simply a url mapping module which
would take a url like /research/user/search and map that to the module
Website::User::Search and it would do a eval "use $module;" (where
$module is untained) before calling the constructor and delegating
construction of the page. I saw the same error at that eval statement
also. Again this was sporadic, but here I would have been simply
compiling the code of modules rather than running them (save for code in
BEGIN blocks etc.).
What I found was if I changed my Website::Proxy module to load all
modules on webserver startup (i.e. in it's own BEGIN block) rather than
on demand then the eval errors there stopped. This seems to imply that
the interpreter is getting into a confused state after some continued
use.
Does anyone have any other suggestions?
=ANYTHING+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.
------------------------------------------------------------------------
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Perrin,
Thanks for your response.
> -----Original Message-----
> From: Perrin Harkins [mailto:pharkins@gmail.com]
> Sent: 26 March 2007 16:12
> To: Shah, Sagar: IT (LDN)
> Cc: modperl@perl.apache.org
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> On 3/26/07, Sagar.Shah@barclayscapital.com
> <Sa...@barclayscapital.com> wrote:
> > The most interesting thing, as I said earlier, is that the
> behaviour is
> > not consistent. If I hit one mod_perl page many many times then
> > eventually I'll get the Insecure Dependency error when I hit a
> > completely _separate_ mod_perl page.
>
> It sounds to me like somewhere in the code you're running, someone is
> trying to set the group ID. It wouldn't surprise me at all to find
> that some common CPAN module you use breaks taint mode. My
> recommendation would be to grep all the code you use in your server
> for anything that might be trying to set the group.
Thanks for the suggestion. Unfortunately I've found no relevant
reference to setgid/gid in my code, my installed cpan code or the CPAN
modules that have come bundled with Perl. Of course that's not to say a
module I've installed isn't calling some complied c code by way of an xs
module that's doing a setgid.
> Alternatively, if you can run your server in single-process mode and
> come up with a repeatable series of steps that cause the error, you
> can work back from the point where you saw the error until you find
> the offending code.
Yes, httpd -X is a good idea. I should have thought of that before. I'll
give that a go and report back to the list.
Thanks for everyone's help so far, please do keep the suggestions
coming.
Regards
Sagar
>
> - Perrin
>
=ANYTHING+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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/26/07, Sagar.Shah@barclayscapital.com
<Sa...@barclayscapital.com> wrote:
> The most interesting thing, as I said earlier, is that the behaviour is
> not consistent. If I hit one mod_perl page many many times then
> eventually I'll get the Insecure Dependency error when I hit a
> completely _separate_ mod_perl page.
It sounds to me like somewhere in the code you're running, someone is
trying to set the group ID. It wouldn't surprise me at all to find
that some common CPAN module you use breaks taint mode. My
recommendation would be to grep all the code you use in your server
for anything that might be trying to set the group.
Alternatively, if you can run your server in single-process mode and
come up with a repeatable series of steps that cause the error, you
can work back from the point where you saw the error until you find
the offending code.
- Perrin
RE: "Insecure dependency in eval while running setgid" error
Posted by Sa...@barclayscapital.com.
Hi Charlie,
Thanks for your response.
I'm afraid I don't use the Taint module. It's not even in my @INC so I'm
reasonably certain that I'm not using it indirectly either.
The fact that there's more than one person running into this issue
raises there the chance there is a bug somewhere in mod_perl. I'm just
not sure how I can produce a simple test case for this. Like yourself,
I've been using my mod_perl setup for some months without any problems.
It's only as we've been porting a new page to mod_perl and seeing a
higher volume of requests that this has become a visible issue.
Like yourself doing a graceful restart calms the issue for a while, but
it does return.
Mod_perl gurus/developers - any ideas?
Sagar
> -----Original Message-----
> From: Charlie Katz [mailto:ckatz@cfa.harvard.edu]
> Sent: 26 March 2007 15:20
> To: modperl@perl.apache.org
> Cc: Shah, Sagar: IT (LDN)
> Subject: Re: "Insecure dependency in eval while running setgid" error
>
> Hi,
>
> I recently ran into a similiar situation, which I asked about
> on this list
> (message subject "inconsistent taint check results").
>
> Do you by any chance "use Taint;" (Taint-0.09) ? I found
> that when I stopped
> using that, the problem went away.
>
> Just a guess.
>
> Regards,
> Charlie Katz
>
>
> On Monday 26 March 2007 7:44 am, Sagar.Shah@barclayscapital.com wrote:
> > I'm getting some quite perplexing behaviour from my
> application under
> > mod_perl and so far I haven't been able to find the cause
> of the issue.
> >
> > I'm finding that pages which load perfectly fine under
> mod_perl most of
> > the time, sometimes fail with the error "Insecure dependency in eval
> > while running setgid".
> > ...
> > And the preceding lines untaint $block completely:
> >
> > # DON'T LOOK NOW! - blindly untainting can make you
> go blind!
> > $block =~ /(.*)/s;
> > $block = $1;
>
> --
> Charlie Katz
> Harvard-Smithsonian Center for Astrophysics
> ckatz@cfa.harvard.edu
>
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Re: "Insecure dependency in eval while running setgid" error
Posted by Charlie Katz <ck...@cfa.harvard.edu>.
Hi,
I recently ran into a similiar situation, which I asked about on this list
(message subject "inconsistent taint check results").
Do you by any chance "use Taint;" (Taint-0.09) ? I found that when I stopped
using that, the problem went away.
Just a guess.
Regards,
Charlie Katz
On Monday 26 March 2007 7:44 am, Sagar.Shah@barclayscapital.com wrote:
> I'm getting some quite perplexing behaviour from my application under
> mod_perl and so far I haven't been able to find the cause of the issue.
>
> I'm finding that pages which load perfectly fine under mod_perl most of
> the time, sometimes fail with the error "Insecure dependency in eval
> while running setgid".
> ...
> And the preceding lines untaint $block completely:
>
> # DON'T LOOK NOW! - blindly untainting can make you go blind!
> $block =~ /(.*)/s;
> $block = $1;
--
Charlie Katz
Harvard-Smithsonian Center for Astrophysics
ckatz@cfa.harvard.edu