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
Re: Apache2::compat from mod_perl 2.0.3 -- multiple issues
Joshua Hoblitt wrote: It seems that compat.pm isn't 'use strict' clean even thou it is declaring this pragma. # Error: Bareword Apache2::ServerUtil::server_root not allowed while strict subs in use at /usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 347, DATA line 9. This error is caused by 'Apache2::ServerUtil::server_root' (note that missing '()') and this repeated in several places through-out compat.pm. you are not the first to report this, but I guess we've let it slip until now. fixed in svn. thanks. Commenting out the 'use strict' at the top of compat.om reveals another more serious error: # Error: Undefined subroutine Apache2::ServerUtil::restart_count called at /usr/lib/perl5/site_perl/5.8.8/i686-linux/Apache2/compat.pm line 76, DATA line 9. Which I assume is supposed to be provided by ServerUtil.so except that this symbol isn't defined in this lib. nm ./Apache2/ServerUtil/ServerUtil.so | grep restart 1cf0 T XS_Apache2__ServerUtil_restart_count U modperl_restart_count Any ideas as to what might have gone wrong in the build? that's strange. did all tests pass for you? we explicitly exercise this in several of the test scripts. keep in mind that lots of this stuff won't work if you just do something like $ perl -cw lib/Apache2/compat.pm you really need to call it from within a live, running mod_perl environment. if you are, please consider sending along a minimal test case that reproduces the issue. see http://perl.apache.org/bugs/ --Geoff
Re: Apache2::AuthenNTLM (0.02) can't connect to server
I did. I was able to look it up using the short name, and the FQDN. Anyway, I had to go with another solution (mod_auth_kerb) On 3/25/07, Aaron Browne [EMAIL PROTECTED] wrote: I am pretty sure the NONCE error occurs when the domain controller names cannot be resolved. Did you try nslookup etc? On Tue, 2007-03-20 at 13:44 -0400, Shawn Kovalchick wrote: I'm trying to set up AuthenNTLM, but can't get connected to my domain controller. I've tried adding domain company.com and search company.com to /etc/resolv.conf. I've tried adding controler1.company.com to the /etc/hosts file. What am I doing wrong? Does Samba need to be set up? Does the server need to be a member of the domain? Below is my configuration: Directory /usr/share/xxx PerlAuthenHandler Apache2::AuthenNTLM AuthType ntlm,basic Require valid-user AuthName xxx PerlAddVar ntdomain DOMAIN controller1 controller2 PerlSetVar defaultdomain DOMAIN PerlSetVar splitdomainprefix 1 PerlSetVar ntlmdebug 3 AllowOverride None Order allow,deny Allow from all /Directory And below is the debug from apache: [2966] AuthenNTLM: Config Domain = domain pdc = controller1 bdc = controller2 [2966] AuthenNTLM: Config Default Domain = DOMAIN [2966] AuthenNTLM: Config Fallback Domain = [2966] AuthenNTLM: Config AuthType = ntlm,basic AuthName = xxx [2966] AuthenNTLM: Config Auth NTLM = 1 Auth Basic = 1 [2966] AuthenNTLM: Config NTLMAuthoritative = on BasicAuthoritative = on [2966] AuthenNTLM: Config Semaphore key = 23754 timeout = 2 [2966] AuthenNTLM: Config SplitDomainPrefix = 1 [2966] AuthenNTLM: Authorization Header not given [Tue Mar 20 13:27:57 2007] [error] Bad/Missing NTLM/Basic Authorization Header for /nagios [2966] AuthenNTLM: Start NTLM Authen handler pid = 2966, connection = 168464048 conn_http_hdr = keep-alive main = cuser = remote_ip = 10.111.40.195 remote_port = 13106 remote_host = version = 0.02 smbhandle = [2966] AuthenNTLM: Object exists user = \ [2966] AuthenNTLM: Authorization Header NTLM TlRMTVNTUAABB4IIAAA= [2966] AuthenNTLM: Got: 78 84 76 77 83 83 80 0 1 0 0 0 7 130 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [2966] AuthenNTLM: protocol=NTLMSSP, type=1, flags1=7(NEGOTIATE_UNICODE,NEGOTIATE_OEM,REQUEST_TARGET), flags2=130(NEGOTIATE_ALWAYS_SIGN,NEGOTIATE_NTLM), domain length=0, domain offset=0, host length=0, host offset=0, host=, domain= [2966] handler type == 1 [2966] AuthenNTLM: Connect to pdc = controller1 bdc = controller2 domain = domain [2966] AuthenNTLM: enter lock [2966] AuthenNTLM: verify handle smbhandle == 0 [Tue Mar 20 13:27:57 2007] [error] Connect to SMB Server failed (pdc = controller1 bdc = controller2 domain = domain error = -11/0) for /nagios [2966] AuthenNTLM: leave lock [Tue Mar 20 13:27:57 2007] [error] Cannot get nonce
internal_redirect ModPerlRegistry
Can I only use internal_redirect in handlers or is it possible to use it within a cgi script calling another cgi script? All the docs I've seen have used handlers . I want to do something different ;) As you know, OK has to be returned immediatly after the internal_redirect so that's telling me it's only used in handlers :( I need to incorporate the output from the internal call into the contents of the external call. I've tried internal_redirect but nothing is returned and the called script isn;t entered. Or, is there another way to achieve the same thing without going through the outside world? Any help would be greatly appreciated. Here's a snippet of the offending code. my $r = $self-_request_rec(); my $server_root = $self-server_root(); my $faq_path = $server_root . '/' . $path; my $ret = $r-internal_redirect( $faq_path ); CIA -Ants - New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: internal_redirect ModPerlRegistry
Answering my own question . yes, it can only be called from content handlers. But any advice on how I can achielve the same result from with cgi scrupts would be great. Thank you. Anthony Gardner [EMAIL PROTECTED] wrote: Can I only use internal_redirect in handlers or is it possible to use it within a cgi script calling another cgi script? All the docs I've seen have used handlers . I want to do something different ;) As you know, OK has to be returned immediatly after the internal_redirect so that's telling me it's only used in handlers :( I need to incorporate the output from the internal call into the contents of the external call. I've tried internal_redirect but nothing is returned and the called script isn;t entered. Or, is there another way to achieve the same thing without going through the outside world? Any help would be greatly appreciated. Here's a snippet of the offending code. my $r = $self-_request_rec(); my $server_root = $self-server_root(); my $faq_path = $server_root . '/' . $path; my $ret = $r-internal_redirect( $faq_path ); CIA -Ants - New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. - What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
RE: Insecure dependency in eval while running setgid error
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:[EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: internal_redirect ModPerlRegistr
On 3/26/07, Anthony Gardner [EMAIL PROTECTED] wrote: Can I only use internal_redirect in handlers or is it possible to use it within a cgi script calling another cgi script? If by CGI script you mean something running ModPerl::Registry, then yes, it works fine. If you mean a perl program called through mod_cgi and not mod_perl, then no. You would have to fake that with LWP or similar. my $r = $self-_request_rec(); That looks pretty scary. Where is the value of $self-_request_rec() coming from? If you keep a RequestRec object around and try to use it in a later request, bad things will happen (segfaults). - Perrin
Re: Insecure dependency in eval while running setgid error
On 3/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] 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
Hi Perrin, Thanks for your response. -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] 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, [EMAIL PROTECTED] [EMAIL PROTECTED] 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: Mod_Perl2 vs. Mod_Perl1, MPM_WORKER....
On Fri, 23 Mar 2007 17:06:18 -0400 Jason Rosenberg [EMAIL PROTECTED] wrote: I¹m just wondering what the mod_perl intelligencia thinks about the choice between using mod_perl1 vs. mod_perl2 Is there a reason not to go with the newer mod_perl2 (and Apache2, of course). Is it stable and well accepted at this point? It seems like a great number of people still use mod_perl1. I can't think of a reason not to go with mod_perl2, I use it daily and have for many months. Further, what success have people had using threading with mod_perl2, using MPM_WORKER? Other than for some testing of modules I haven't found a need to use either the threaded or worker MPMs. - Frank Wiles [EMAIL PROTECTED] http://www.wiles.org -
Re: MP1 Security issue
Chris Shiflett wrote: That's a weak defense. If you're a proponent of full disclosure, say so, but don't use ignorance as your defense in the same email where you claim to not be a dumb guy. I am a dumb guy, and I would have done the exact same thing Randal did. I just don't think about security in terms of secrecy. It's not a full disclosure thing at all, at least for me. Despite the (perceived) violation of protocol, Randal's message did light a fire under the asses of a lot of mod_perl developers, and made known a potential security issue. I'd say that's mission accomplished. Rob
Re: internal_redirect ModPerlRegistr
On Monday 26 March 2007 16:57, Perrin Harkins wrote:
On 3/26/07, Anthony Gardner [EMAIL PROTECTED] wrote:
Can I only use internal_redirect in handlers or is it possible to use it
within a cgi script calling another cgi script?
If by CGI script you mean something running ModPerl::Registry, then
yes, it works fine. If you mean a perl program called through mod_cgi
and not mod_perl, then no. You would have to fake that with LWP or
similar.
Not entirely true, a CGI script (mod_cgid?) can generate an internal redirect
saying
Status: 200
Location: /path/to/other.html
Both mod_cgi and mod_cgid contain this code:
if (location location[0] == '/' r-status == 200) {
/* This redirect needs to be a GET no matter what the original
* method was.
*/
r-method = apr_pstrdup(r-pool, GET);
r-method_number = M_GET;
/* We already read the message body (if any), so don't allow
* the redirected request to think it has one. We can ignore
* Transfer-Encoding, since we used REQUEST_CHUNKED_ERROR.
*/
apr_table_unset(r-headers_in, Content-Length);
ap_internal_redirect_handler(location, r);
return OK;
}
As for Modperl::Registry, you need to use the perl-script handler and enable
PerlOptions +ParseHeaders. Then the same approach works also for Registry
scripts, see modperl_cgi.c:modperl_cgi_header_parse().
Torsten
pgp9eg4cXfAVB.pgp
Description: PGP signature
Re: internal_redirect ModPerlRegistr
The script is running under ModPerlRegistry but nothing is happening. After posting this problem, I read that internal_redirect can only be called from a content handler. So, am I right in now thinking, because my cgi script gets wrapped by a handler, it's considered a content handler? If so, why oh why isn;t it working :( As for the $r, it's coming from Apache-request() but we are experiencing segfaults Perrin Harkins [EMAIL PROTECTED] wrote: On 3/26/07, Anthony Gardner wrote: Can I only use internal_redirect in handlers or is it possible to use it within a cgi script calling another cgi script? If by CGI script you mean something running ModPerl::Registry, then yes, it works fine. If you mean a perl program called through mod_cgi and not mod_perl, then no. You would have to fake that with LWP or similar. my $r = $self-_request_rec(); That looks pretty scary. Where is the value of $self-_request_rec() coming from? If you keep a RequestRec object around and try to use it in a later request, bad things will happen (segfaults). - Perrin - What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
Re: internal_redirect ModPerlRegistr
On 3/26/07, Torsten Foertsch [EMAIL PROTECTED] wrote:
Not entirely true, a CGI script (mod_cgid?) can generate an internal redirect
saying
Status: 200
Location: /path/to/other.html
Both mod_cgi and mod_cgid contain this code:
if (location location[0] == '/' r-status == 200) {
/* This redirect needs to be a GET no matter what the original
* method was.
*/
r-method = apr_pstrdup(r-pool, GET);
r-method_number = M_GET;
/* We already read the message body (if any), so don't allow
* the redirected request to think it has one. We can ignore
* Transfer-Encoding, since we used REQUEST_CHUNKED_ERROR.
*/
apr_table_unset(r-headers_in, Content-Length);
ap_internal_redirect_handler(location, r);
return OK;
}
Interesting. Now that I look at what Anthony wanted to do though, it
doesn't seem very useful for his case, since he wants to collect the
output. In fact, an internal_redirect in general is not right for
that. You need a subrequest instead.
As for Modperl::Registry, you need to use the perl-script handler and enable
PerlOptions +ParseHeaders. Then the same approach works also for Registry
scripts, see modperl_cgi.c:modperl_cgi_header_parse().
In ModPerl::Registry, you don't need to resort to tricks like that.
You get passed an Apache2::RequestRec object to do whatever you like
with.
- Perrin
Re: internal_redirect ModPerlRegist
On 3/26/07, Anthony Gardner [EMAIL PROTECTED] wrote: The script is running under ModPerlRegistry but nothing is happening. What's your definition of nothing in this case? So, am I right in now thinking, because my cgi script gets wrapped by a handler, it's considered a content handler? Yes. But see my other response -- you probably don't want internal_redirect if you're trying to gather up the output. As for the $r, it's coming from Apache-request() but we are experiencing segfaults Are you using mod_perl 2? If so, you should be calling it like this: $r = Apache2::RequestUtil-request; The code you showed looked like it was trying to cache $r in some other object, which you have to be really careful about. You're likely to accidentally keep one around and try to use the $r from a previous request, especially if you get into subrequests and internal_redirects. - Perrin
Re: Mod_Perl2 vs. Mod_Perl1, MPM_WORKER....
On 3/26/07, Frank Wiles [EMAIL PROTECTED] wrote: Further, what success have people had using threading with mod_perl2, using MPM_WORKER? Other than for some testing of modules I haven't found a need to use either the threaded or worker MPMs. I'd second that. The general advice is to avoid using threads if you are on a unix-like system. They are slower and use more memory than the prefork MPM on those systems. - Perrin
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? =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: internal_redirect ModPerlRegistr
On 3/26/07, Torsten Foertsch [EMAIL PROTECTED] wrote: switch to mp2. It's much more stable. I'm not aware of any stability issues in mp1. Switch to mp2 if you want the new features. You don't need to switch for stability. - Perrin
Re: internal_redirect ModPerlRegistr
Perrin Harkins wrote: On 3/26/07, Torsten Foertsch [EMAIL PROTECTED] wrote: switch to mp2. It's much more stable. I'm not aware of any stability issues in mp1. Switch to mp2 if you want the new features. You don't need to switch for stability. In addition to new features, there is a speed advantage. I just spent a good deal of time benchmarking mp1 vs mp2 on a project. Mp2 was faster in terms of elapsed request time taken, in the double digits percentage wise vs mp1 for the exact same configuration for small amounts of data being returned by the response phase. I can't post the exact details due to an nda, but I can say with confidence that it's definitely faster :)
Re: internal_redirect ModPerlRegistr
This is MP2 ... actually RHE 1.99. We have compiled a test MP2 but still get seg faults. Am not at work now but will look at this further tomorrow. Torsten Foertsch [EMAIL PROTECTED] wrote: On Monday 26 March 2007 17:51, Anthony Gardner wrote: As for the $r, it's coming from Apache-request() So, it's mp1 then. Set PerlSendHeader to On then try the approach given in my previous mail. I don't know for sure because I have switched to mp2 several years ago. but we are experiencing segfaults switch to mp2. It's much more stable. Torsten - What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
Re: Mod_Perl2 vs. Mod_Perl1, MPM_WORKER....
Perrin Harkins wrote: On 3/26/07, Frank Wiles [EMAIL PROTECTED] wrote: Further, what success have people had using threading with mod_perl2, using MPM_WORKER? Other than for some testing of modules I haven't found a need to use either the threaded or worker MPMs. I'd second that. The general advice is to avoid using threads if you are on a unix-like system. They are slower and use more memory than the prefork MPM on those systems. Hmmm, been using it here for about 6 years. Careful with FUD, threading by definition is lighter weight than processes, although the older Linux threads certainly didn't measure up. Bill
Re: internal_redirect ModPerlRegist
Nothing means .. not working. It's not entering the called script. As for $r, the $self is actually a WWW::Utils package and some of the routines within that package call on Apache-request when running under MP. Nothing gets stored. I know the called CGI script is passed $r but I thought it was better/cleaner to call it as I have. I'm not at work now so will have to look at this further tomorrow. As long as I know I should be able to do it, then I have a goal. I tried sub requests . from memory, sth like $sub_rec = $r-lookup_file( '/path/to/script'); $rc = $sub_rec-run() and although that entered the script, I didn;t get 200 returned. Plus, where would the content be? Stored in the $sub_rec? Will look into this further tomorrow. Thanks very, very much for all your help thus far .. will get back to you ;) -Ants Perrin Harkins [EMAIL PROTECTED] wrote: On 3/26/07, Anthony Gardner wrote: The script is running under ModPerlRegistry but nothing is happening. What's your definition of nothing in this case? So, am I right in now thinking, because my cgi script gets wrapped by a handler, it's considered a content handler? Yes. But see my other response -- you probably don't want internal_redirect if you're trying to gather up the output. As for the $r, it's coming from Apache-request() but we are experiencing segfaults Are you using mod_perl 2? If so, you should be calling it like this: $r = Apache2::RequestUtil-request; The code you showed looked like it was trying to cache $r in some other object, which you have to be really careful about. You're likely to accidentally keep one around and try to use the $r from a previous request, especially if you get into subrequests and internal_redirects. - Perrin - Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.
Re: MP1 Security issue
On Mar 26, 2007, at 12:25 PM, Perrin Harkins wrote: That's easy to say in this specific case, since the actual threat is so tiny that it didn't make much difference. You guys probably wouldn't think it was such a good idea if it had been a more serious exploit and someone had used it to compromise your servers before a fix was available. Keep in mind -- in this specific case the discussion was such ( the first 3 emails ): From: [EMAIL PROTECTED] Date: March 22, 2007 11:57:41 AM EDT Subject:[mp1] PerlRun fails if path_info contains special symbols From: [EMAIL PROTECTED] Date: March 22, 2007 11:04:37 PM EDT Subject:Re: [mp1] PerlRun fails if path_info contains special symbols From: merlyn@stonehenge.com Date: March 22, 2007 11:20:48 PM EDT Subject: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) It's not the case that Randal found an exploit and said Hey developers ! there's a security breach I found -- which a lot of these postings insinuate. Alex found the issue, and reported it as a bug. Perrin asked, 'do you think you can patch it?' Randal replied wait - this isn't a bug, its a security issue. this needs faster attention Randal didn't raise an report an new security threat -- he re- categorized an active bug discussion as a security threat. People have commented This isn't the proper way to report a security threat. Well, right now ModPerl doesn't have a published protocol for dealing with security threats. In fact, there's no security policy *at all* on the mod perl website. There also aren't any listings or contact addresses for project maintainers -- the closest thing available is a current + historical intermingled list of people who have contributed. All the Repot a bug information make it very clear that everything should be posted to the mailing list for discussion, and there is no mention of if you believe this could have security implications, please do not post it publicly. That said, I think the suggestion to email info , support , security as a first step is ridiculous -- they're not addresses universally used across projects , and shouldn't be expected to work as such. There's about as much rationale to crossing your fingers and hoping someone sees those messages as writing to [EMAIL PROTECTED] . I suggest the core developers devise some protocol + notification scheme / contact addresses they feel comfortable with, and publish it on these pages: Reporting bugs http://perl.apache.org/bugs/index.html http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Getting Help http://perl.apache.org/help/index.html It could be as simple as: If you think you have found a security threat, please email ___ and give us 7 days to respond and work out a disclosure scheme with you. We're all fortunate that this discussion happened around a trivial threat in a largely insignificant/unused feature -- but there should be a system or directions in place for the unlikely event that someone else finds a serious bug and follows every piece of information on the website that says just post it to the mailing list. // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Mod_Perl2 vs. Mod_Perl1, MPM_WORKER....
On 3/26/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Careful with FUD, threading by definition is lighter weight than processes, although the older Linux threads certainly didn't measure up. We're not talking about Linux threads or apache threaded MPMs in general here. The issue is Perl threads. They are implemented in a way that makes them slower and heavier than a prefork model in most cases, due to duplication without copy-on-write benefits. This has been pretty thoroughly covered before so please check the mailing archives if you want more information. For static content, the worker MPM seems to work very well. I expect it would be a good choice for your reverse proxy server. - Perrin
Re: internal_redirect ModPerlRegistr
On Monday 26 March 2007, Anthony Gardner wrote: This is MP2 ... actually RHE 1.99. We have compiled a test MP2 but still get seg faults. Ah, that's possibly not actually MP2. RH shipped a pre-release version of MP, and there were a lot of changes and bug fixes after that point (including a namespace change for a lot of the modules). If you're using anything tagged 1.99x, it's an unsupported version and you really need to upgrade to a stable release of MP2.
Re: MP1 Security issue
Jonathan == Jonathan Vanasco [EMAIL PROTECTED] writes: Jonathan Randal didn't raise an report an new security threat -- he re- Jonathan categorized an active bug discussion as a security threat. Just for the record, I'm now clear (thanks to new information) that I handled this poorly, and will handle it differently the next time. I apologize for any stress or grief, or even break-in, that may have resulted from my actions. Jonathan People have commented This isn't the proper way to report a Jonathan security threat. Well, right now ModPerl doesn't have a published Jonathan protocol for dealing with security threats. I *do* strongly support this statement though. Even after having been LARTed, googling for security mod_perl didn't reveal anything in the first ten hits that would be remotely useful here. This *can* be fixed for the future. (Nudge to the developers.) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: MP1 Security issue
Randal L. Schwartz wrote: Jonathan == Jonathan Vanasco [EMAIL PROTECTED] writes: Jonathan Randal didn't raise an report an new security threat -- he re- Jonathan categorized an active bug discussion as a security threat. Just for the record, I'm now clear (thanks to new information) that I handled this poorly, and will handle it differently the next time. in all fairness, I do appreciate you paying attention and speaking up. if the security implications had not been brought up there's always the possibility that Evil Guy would have seen the exploit, that the developers wouldn't have patched things fast enough, and that much chaos would have been the result. I just wish we hadn't given the bad guys such a clear roadmap to the chaos :) I apologize for any stress or grief, or even break-in, that may have resulted from my actions. thankfully, I don't think the risk is as great as anybody thought at first. but just to put things in perspective, the top two mod_perl shops transact _billions_ of dollars through mod_perl servers, so a more serious security threat... well, I think that could have had an incredible impact on all of us who work in open source, not just our little corner of it. Jonathan People have commented This isn't the proper way to report a Jonathan security threat. Well, right now ModPerl doesn't have a published Jonathan protocol for dealing with security threats. I *do* strongly support this statement though. Even after having been LARTed, googling for security mod_perl didn't reveal anything in the first ten hits that would be remotely useful here. This *can* be fixed for the future. (Nudge to the developers.) I had actually started patching the documentation before jonathan said anything, so expect something soonish. still, short of an official channel to report security issues, it's always probably safe to say hey, I think this poses a security issue. what's the best way to handle things? no matter which mailing list you're on :) --Geoff
svn commit: r522501 - /perl/modperl/branches/1.x/MANIFEST
Author: geoff Date: Mon Mar 26 05:44:14 2007 New Revision: 522501 URL: http://svn.apache.org/viewvc?view=revrev=522501 Log: add in regex.t for distribution Modified: perl/modperl/branches/1.x/MANIFEST Modified: perl/modperl/branches/1.x/MANIFEST URL: http://svn.apache.org/viewvc/perl/modperl/branches/1.x/MANIFEST?view=diffrev=522501r1=522500r2=522501 == --- perl/modperl/branches/1.x/MANIFEST (original) +++ perl/modperl/branches/1.x/MANIFEST Mon Mar 26 05:44:14 2007 @@ -199,6 +199,7 @@ t/modules/perlrun.t t/modules/perlrunxs.t t/modules/psections.t +t/modules/regex.t t/modules/request.t t/modules/sandwich.t t/modules/src.t
svn commit: r522508 - in /perl/modperl/trunk: Changes lib/Apache2/compat.pm
Author: geoff
Date: Mon Mar 26 06:04:00 2007
New Revision: 522508
URL: http://svn.apache.org/viewvc?view=revrev=522508
Log:
fixed Apache2::compat Apache2::ServerUtil::server_root() resolution
issues [Joshua Hoblitt]
Modified:
perl/modperl/trunk/Changes
perl/modperl/trunk/lib/Apache2/compat.pm
Modified: perl/modperl/trunk/Changes
URL:
http://svn.apache.org/viewvc/perl/modperl/trunk/Changes?view=diffrev=522508r1=522507r2=522508
==
--- perl/modperl/trunk/Changes (original)
+++ perl/modperl/trunk/Changes Mon Mar 26 06:04:00 2007
@@ -12,6 +12,9 @@
=item 2.0.4-dev
+fixed Apache2::compat Apache2::ServerUtil::server_root() resolution
+issues [Joshua Hoblitt]
+
*) SECURITY: CVE-2007-1349 (cve.mitre.org)
fix unescaped variable interprolation in regular expression
[Randal L. Schwartz merlyn@stonehenge.com, Fred Moyer [EMAIL PROTECTED]]
Modified: perl/modperl/trunk/lib/Apache2/compat.pm
URL:
http://svn.apache.org/viewvc/perl/modperl/trunk/lib/Apache2/compat.pm?view=diffrev=522508r1=522507r2=522508
==
--- perl/modperl/trunk/lib/Apache2/compat.pm (original)
+++ perl/modperl/trunk/lib/Apache2/compat.pm Mon Mar 26 06:04:00 2007
@@ -310,7 +310,7 @@
package Apache::Server;
# XXX: is that good enough? see modperl/src/modules/perl/mod_perl.c:367
-our $CWD = Apache2::ServerUtil::server_root;
+our $CWD = Apache2::ServerUtil::server_root();
our $AddPerlVersion = 1;
@@ -344,7 +344,7 @@
return File::Spec-catfile(@_);
}
else {
-File::Spec-catfile(Apache2::ServerUtil::server_root, @_);
+File::Spec-catfile(Apache2::ServerUtil::server_root(), @_);
}
}
@@ -596,7 +596,7 @@
sub server_root_relative {
my $r = shift;
-File::Spec-catfile(Apache2::ServerUtil::server_root, @_);
+File::Spec-catfile(Apache2::ServerUtil::server_root(), @_);
}
sub clear_rgy_endav {
svn commit: r522521 - in /perl/modperl/branches/1.x: ./ Changes Makefile.PL lib/Apache/SizeLimit.pm
Author: pgollucci Date: Mon Mar 26 07:16:38 2007 New Revision: 522521 URL: http://svn.apache.org/viewvc?view=revrev=522521 Log: pulled the seperate A-SL back out and restored lib/Apache/[EMAIL PROTECTED] (will restore this after the 1.30 security release) Added: perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm Modified: perl/modperl/branches/1.x/ (props changed) perl/modperl/branches/1.x/Changes perl/modperl/branches/1.x/Makefile.PL Propchange: perl/modperl/branches/1.x/ -- --- svn:externals (original) +++ svn:externals Mon Mar 26 07:16:38 2007 @@ -1,2 +1 @@ -Apache-SizeLimit https://svn.apache.org/repos/asf/perl/Apache-SizeLimit/trunk Modified: perl/modperl/branches/1.x/Changes URL: http://svn.apache.org/viewvc/perl/modperl/branches/1.x/Changes?view=diffrev=522521r1=522520r2=522521 == --- perl/modperl/branches/1.x/Changes (original) +++ perl/modperl/branches/1.x/Changes Mon Mar 26 07:16:38 2007 @@ -16,11 +16,6 @@ reported by Alex Solovey [Randal L. Schwartz merlyn@stonehenge.com, Fred Moyer [EMAIL PROTECTED]] -Pull in the new Apache-SizeLimit from -http://svn.apache.org/repos/asf/perl/Apache-SizeLimit/trunk -and obsolete the previous lib/Apache/SizeLimit.pm. -[Philip M. Gollucci] - Fix an Apache::(Registry|PerlRun) bug caused by special characters in the url [EMAIL PROTECTED] Modified: perl/modperl/branches/1.x/Makefile.PL URL: http://svn.apache.org/viewvc/perl/modperl/branches/1.x/Makefile.PL?view=diffrev=522521r1=522520r2=522521 == --- perl/modperl/branches/1.x/Makefile.PL (original) +++ perl/modperl/branches/1.x/Makefile.PL Mon Mar 26 07:16:38 2007 @@ -1531,7 +1531,7 @@ q( -test: pure_all start_httpd run_tests kill_httpd run_apache_sizelimit_tests +test: pure_all start_httpd run_tests kill_httpd ); my $have_so = $USE_DSO || ($APACI_ARGS =~ /--enable-shared=/); @@ -1570,10 +1570,6 @@ run_tests: $(FULLPERL) $(MP_TEST_SCRIPT) $(TEST_VERBOSE) - -run_apache_sizelimit_tests: - @(echo ; echo ; echo) - cd Apache-SizeLimit ; $(MAKE) test ), $my_test, Added: perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm URL: http://svn.apache.org/viewvc/perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm?view=autorev=522521 == --- perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm (added) +++ perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm Mon Mar 26 07:16:38 2007 @@ -0,0 +1,348 @@ +package Apache::SizeLimit; + +=head1 NAME + +Apache::SizeLimit - Because size does matter. + +=head1 SYNOPSIS + +This module allows you to kill off Apache httpd processes if they grow too +large. You can choose to set up the process size limiter to check the +process size on every request: + +# in your startup.pl: +use Apache::SizeLimit; +# sizes are in KB +$Apache::SizeLimit::MAX_PROCESS_SIZE = 1; # 10MB +$Apache::SizeLimit::MIN_SHARE_SIZE= 1000; # 1MB +$Apache::SizeLimit::MAX_UNSHARED_SIZE = 12000; # 12MB + +# in your httpd.conf: +PerlCleanupHandler Apache::SizeLimit + +Or you can just check those requests that are likely to get big, such as +CGI requests. This way of checking is also easier for those who are mostly +just running CGI.pm/Registry scripts: + +# in your CGI: +use Apache::SizeLimit; +Apache::SizeLimit::setmax(1); # Max size in KB +Apache::SizeLimit::setmin(1000); # Min share in KB +Apache::SizeLimit::setmax_unshared(12000); # Max unshared size in KB + +Since checking the process size can take a few system calls on some +platforms (e.g. linux), you may want to only check the process size every +N times. To do so, put this in your startup.pl or CGI: + +$Apache::SizeLimit::CHECK_EVERY_N_REQUESTS = 2; + +This will only check the process size every other time the process size +checker is called. + +=head1 DESCRIPTION + +This module is highly platform dependent, please read the CAVEATS section. + +This module was written in response to questions on the mod_perl mailing +list on how to tell the httpd process to exit if it gets too big. + +Actually there are two big reasons your httpd children will grow. First, +it could have a bug that causes the process to increase in size +dramatically, until your system starts swapping. Second, your process just +does stuff that requires a lot of memory, and the more different kinds of +requests your server handles, the larger the httpd processes grow over +time. + +This module will not really help you with the first problem. For that you +should probably look into Apache::Resource or some other means of setting a +limit on the data size of your program. BSD-ish systems have setrlimit() +which will croak your memory gobbling
svn commit: r522534 - /perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
Author: pgollucci
Date: Mon Mar 26 07:54:40 2007
New Revision: 522534
URL: http://svn.apache.org/viewvc?view=revrev=522534
Log:
copied unchanged from
https://svn.apache.org/repos/asf/perl/Apache-SizeLimit/tags/0_9/lib/Apache/SizeLimit.pm
Modified:
perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
Modified: perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
URL:
http://svn.apache.org/viewvc/perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm?view=diffrev=522534r1=522533r2=522534
==
--- perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm (original)
+++ perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm Mon Mar 26 07:54:40 2007
@@ -1,338 +1,688 @@
+# Copyright 2001-2006 The Apache Software Foundation or its licensors, as
+# applicable.
+#
+# Licensed under the Apache License, Version 2.0 (the License);
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an AS IS BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
package Apache::SizeLimit;
-=head1 NAME
+use Apache::Constants qw(DECLINED OK);
+use Config;
+use strict;
+use vars qw(
+$VERSION
+$REQUEST_COUNT
+$START_TIME
+$USE_SMAPS
+);
-Apache::SizeLimit - Because size does matter.
+$VERSION = '0.9';
-=head1 SYNOPSIS
+__PACKAGE__-set_check_interval(1);
-This module allows you to kill off Apache httpd processes if they grow too
-large. You can choose to set up the process size limiter to check the
-process size on every request:
-
-# in your startup.pl:
-use Apache::SizeLimit;
-# sizes are in KB
-$Apache::SizeLimit::MAX_PROCESS_SIZE = 1; # 10MB
-$Apache::SizeLimit::MIN_SHARE_SIZE= 1000; # 1MB
-$Apache::SizeLimit::MAX_UNSHARED_SIZE = 12000; # 12MB
+$REQUEST_COUNT = 1;
+$USE_SMAPS = 1;
-# in your httpd.conf:
-PerlCleanupHandler Apache::SizeLimit
+use constant IS_WIN32 = $Config{'osname'} eq 'MSWin32' ? 1 : 0;
-Or you can just check those requests that are likely to get big, such as
-CGI requests. This way of checking is also easier for those who are mostly
-just running CGI.pm/Registry scripts:
-
-# in your CGI:
-use Apache::SizeLimit;
-Apache::SizeLimit::setmax(1); # Max size in KB
-Apache::SizeLimit::setmin(1000); # Min share in KB
-Apache::SizeLimit::setmax_unshared(12000); # Max unshared size in KB
-Since checking the process size can take a few system calls on some
-platforms (e.g. linux), you may want to only check the process size every
-N times. To do so, put this in your startup.pl or CGI:
+use vars qw( $MAX_PROCESS_SIZE );
+sub set_max_process_size {
+my $class = shift;
-$Apache::SizeLimit::CHECK_EVERY_N_REQUESTS = 2;
+$MAX_PROCESS_SIZE = shift;
+}
-This will only check the process size every other time the process size
-checker is called.
+use vars qw( $MAX_UNSHARED_SIZE );
+sub set_max_unshared_size {
+my $class = shift;
-=head1 DESCRIPTION
+$MAX_UNSHARED_SIZE = shift;
+}
-This module is highly platform dependent, please read the CAVEATS section.
+use vars qw( $MIN_SHARE_SIZE );
+sub set_min_shared_size {
+my $class = shift;
-This module was written in response to questions on the mod_perl mailing
-list on how to tell the httpd process to exit if it gets too big.
+$MIN_SHARE_SIZE = shift;
+}
-Actually there are two big reasons your httpd children will grow. First,
-it could have a bug that causes the process to increase in size
-dramatically, until your system starts swapping. Second, your process just
-does stuff that requires a lot of memory, and the more different kinds of
-requests your server handles, the larger the httpd processes grow over
-time.
-
-This module will not really help you with the first problem. For that you
-should probably look into Apache::Resource or some other means of setting a
-limit on the data size of your program. BSD-ish systems have setrlimit()
-which will croak your memory gobbling processes. However it is a little
-violent, terminating your process in mid-request.
-
-This module attempts to solve the second situation where your process
-slowly grows over time. The idea is to check the memory usage after every
-request, and if it exceeds a threshold, exit gracefully.
-
-By using this module, you should be able to discontinue using the Apache
-configuration directive BMaxRequestsPerChild, although for some folks,
-using both in combination does the job. Personally, I just use the
-technique shown in this module and set my MaxRequestsPerChild value to
-6000.
+use vars qw(
svn commit: r522536 - /perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
Author: pgollucci
Date: Mon Mar 26 07:58:19 2007
New Revision: 522536
URL: http://svn.apache.org/viewvc?view=revrev=522536
Log:
apply
Fix Can't call method child_terminate on an undefined value
By add_cleanup_handler() pass $r to _exit_if_to_big() via shift
[David Wheeler [EMAIL PROTECTED]]
from http://svn.apache.org/viewvc?view=revrevision=428211
Modified:
perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
Modified: perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
URL:
http://svn.apache.org/viewvc/perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm?view=diffrev=522536r1=522535r2=522536
==
--- perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm (original)
+++ perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm Mon Mar 26 07:58:19 2007
@@ -92,7 +92,7 @@
# PerlCleanupHandler phase. That means that there's no way to use
# $r-get_handlers() to check the results of calling this method.
$r-push_handlers( 'PerlCleanupHandler',
- sub { $class-_exit_if_too_big() } );
+ sub { $class-_exit_if_too_big(shift) } );
$r-pnotes( size_limit_cleanup = 1 );
}
svn commit: r522540 - in /perl/Apache-SizeLimit: trunk-unstable/ trunk/
Author: pgollucci Date: Mon Mar 26 08:14:23 2007 New Revision: 522540 URL: http://svn.apache.org/viewvc?view=revrev=522540 Log: move trunk out of the way for now -- its unstable Added: perl/Apache-SizeLimit/trunk-unstable/ - copied from r522539, perl/Apache-SizeLimit/trunk/ Removed: perl/Apache-SizeLimit/trunk/
svn commit: r522541 - /perl/Apache-SizeLimit/trunk/
Author: pgollucci Date: Mon Mar 26 08:14:56 2007 New Revision: 522541 URL: http://svn.apache.org/viewvc?view=revrev=522541 Log: copy 0_9 back to trunk Added: perl/Apache-SizeLimit/trunk/ - copied from r522540, perl/Apache-SizeLimit/tags/0_9/
svn commit: r522543 - in /perl/Apache-SizeLimit/trunk: Changes lib/Apache/SizeLimit.pm
Author: pgollucci
Date: Mon Mar 26 08:19:01 2007
New Revision: 522543
URL: http://svn.apache.org/viewvc?view=revrev=522543
Log:
apply
http://svn.apache.org/viewvc?view=revrevision=428211
on top of the new trunk
Modified:
perl/Apache-SizeLimit/trunk/Changes
perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm
Modified: perl/Apache-SizeLimit/trunk/Changes
URL:
http://svn.apache.org/viewvc/perl/Apache-SizeLimit/trunk/Changes?view=diffrev=522543r1=522542r2=522543
==
--- perl/Apache-SizeLimit/trunk/Changes (original)
+++ perl/Apache-SizeLimit/trunk/Changes Mon Mar 26 08:19:01 2007
@@ -8,6 +8,10 @@
=item 0.9 2006-07-12
+Fix Can't call method child_terminate on an undefined value
+By add_cleanup_handler() pass $r to _exit_if_to_big() via shift
+[David Wheeler [EMAIL PROTECTED]]
+
Copied from the mod_perl 1 core for an independent CPAN release.
[Philip M. Gollucci [EMAIL PROTECTED]]
Modified: perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm
URL:
http://svn.apache.org/viewvc/perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm?view=diffrev=522543r1=522542r2=522543
==
--- perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm (original)
+++ perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm Mon Mar 26 08:19:01 2007
@@ -92,7 +92,7 @@
# PerlCleanupHandler phase. That means that there's no way to use
# $r-get_handlers() to check the results of calling this method.
$r-push_handlers( 'PerlCleanupHandler',
- sub { $class-_exit_if_too_big() } );
+ sub { $class-_exit_if_too_big(shift) } );
$r-pnotes( size_limit_cleanup = 1 );
}
svn commit: r522544 - /perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm
Author: pgollucci Date: Mon Mar 26 08:25:46 2007 New Revision: 522544 URL: http://svn.apache.org/viewvc?view=revrev=522544 Log: bumb version to match A-SL Modified: perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm Modified: perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm URL: http://svn.apache.org/viewvc/perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm?view=diffrev=522544r1=522543r2=522544 == --- perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm (original) +++ perl/modperl/branches/1.x/lib/Apache/SizeLimit.pm Mon Mar 26 08:25:46 2007 @@ -25,7 +25,7 @@ $USE_SMAPS ); -$VERSION = '0.9'; +$VERSION = '0.91-dev'; __PACKAGE__-set_check_interval(1);
svn commit: r522671 - /perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm
Author: gozer Date: Mon Mar 26 17:12:22 2007 New Revision: 522671 URL: http://svn.apache.org/viewvc?view=revrev=522671 Log: should be 0.91 by now Modified: perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm Modified: perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm URL: http://svn.apache.org/viewvc/perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm?view=diffrev=522671r1=522670r2=522671 == --- perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm (original) +++ perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm Mon Mar 26 17:12:22 2007 @@ -25,7 +25,7 @@ $USE_SMAPS ); -$VERSION = '0.9'; +$VERSION = '0.91'; __PACKAGE__-set_check_interval(1);
svn commit: r522672 - /perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm
Author: gozer Date: Mon Mar 26 17:14:13 2007 New Revision: 522672 URL: http://svn.apache.org/viewvc?view=revrev=522672 Log: undo change 522670 Modified: perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm Modified: perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm URL: http://svn.apache.org/viewvc/perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm?view=diffrev=522672r1=522671r2=522672 == --- perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm (original) +++ perl/Apache-SizeLimit/trunk/lib/Apache/SizeLimit.pm Mon Mar 26 17:14:13 2007 @@ -25,7 +25,7 @@ $USE_SMAPS ); -$VERSION = '0.91'; +$VERSION = '0.9'; __PACKAGE__-set_check_interval(1);
