Security Related BUG within ModPerl 2.0.4

Re: Security Related BUG within ModPerl 2.0.4

> I would like to report a security related bug within ModPerl 2.0.4, 
> though prefer not to disclose the details to  a public channel.

The appropriate secure channel for all ASF related security vulnerability
reporting is the closed list, security <at> apache.org, which will be triaged
to the appropriate committers or committee.

Re: Security Related BUG within ModPerl 2.0.4

William A. Rowe, Jr. wrote:
>> I would like to report a security related bug within ModPerl 2.0.4,
>> though prefer not to disclose the details to  a public channel.
> 
> The appropriate secure channel for all ASF related security vulnerability
> reporting is the closed list, security <at> apache.org, which will be triaged
> to the appropriate committers or committee.

and thanks for treating a potential security vulnerability in a
thoughtful manner.

--Geoff

Re: tUsing module

On Fri, 27 Feb 2009, Justin Wyllie wrote:

> I want to instantiate an object just once in the lifetime
> of a script, not on every request.   I'm used to Mason
> where you can use Mason's <%once> block.   In mod_perl
> proper would the equivalent be to instantiate it in a
> BEGIN block? But it would need to be in scope for  the
> whole script..

You are using straight CGI, or using ModPerl::Registry?

If using registry, you should be able to instantiate the
object just by putting it in package scope (anywhere.)
Same is true for a proper handler.

If using straight CGI, you probably can't do this, because
the interpreter gets started up fresh for every hit to the
url.

Mark

get backtrace emailed when code dies running under ModPerl::RegistryPrefork?

As I've mentioned in previous posts, I'm migrating from an older
environment to a new environment with mod_perl 2.

With mod_perl 1.x we had VERY OLD customised version of CGI::Carp (with
fatalsToBrowser) printing an error to the browser AND sending an email
with backtrace and environment information when the code died with a
runtime errors.

According to the docs CGI::Carp doesn't function properly with
fatalToBrowser under mod_perl 2.  The confusing thing is that right
below the fatalsToBrowser documentation it talks about set_die_handler.
Its not exactly clear as to whether set_die_handler doesn't work under
mod_perl 2 or not.

Is anyone using CGI::Carp for backtrace reporting?  Is there an
alternative that someone knows about if CGI::Carp isn't an option?

Re: get backtrace emailed when code dies running under ModPerl::RegistryPrefork?

On Mon, Mar 2, 2009 at 9:54 AM, Matthew Lenz <matthew <at> nocturnal.org> wrote:
> According to the docs CGI::Carp doesn't function properly with
> fatalToBrowser under mod_perl 2.

I'm not sure if that's accurate or not, but setting a $SIG{__DIE__}
handler should work fine.  BTW, I assume you mean stacktrace, not
backtrace, which is usually associated with core dumps.

- Perrin

Re: get backtrace emailed when code dies running under ModPerl::RegistryPrefork?

On Mon, 2009-03-02 at 10:20 -0500, Perrin Harkins wrote:
> On Mon, Mar 2, 2009 at 9:54 AM, Matthew Lenz <matthew <at> nocturnal.org> wrote:
> > According to the docs CGI::Carp doesn't function properly with
> > fatalToBrowser under mod_perl 2.
> 
> I'm not sure if that's accurate or not, but setting a $SIG{__DIE__}
> handler should work fine.

Isn't that basically what fatalsToBrowser does?  You'd think that the
CGI/Carp developer(s) would have been able to get it working with
mod_perl 2.

I can try it though.  Will sticking the $SIG{__DIE__} in the startup.pl
script be sufficient?

> BTW, I assume you mean stacktrace, not
> backtrace, which is usually associated with core dumps.

HAHA, yes.  I was just getting ready to correct myself :)  Thanks for
beating me to it.

> - Perrin

Re: get backtrace emailed when code dies running under ModPerl::RegistryPrefork?

Perrin Harkins wrote:

> I'm not sure if that's accurate or not, but setting a $SIG{__DIE__}
> handler should work fine.

You don't even need to use a __DIE__ handler. mod_perl will place any runtime 
errors into $r->notes('error-notes'). I don't like my errors going to the 
browser (only really works if your content is HTML anyway) but for the email I 
usually use an Apache cleanup handler. That way it gets sent after the client 
request has returned, so they don't have to wait on it.

I use something like this:

# in httpd.conf where you need it
PerlCleanupHandler MyProject::ApacheCleanup

# in MyProject/ApacheCleanup.pm
package MyProject::ApacheCleanup;
use Apache::Constants qw(:common);
sub handler ($$) {
     my ($class, $r) =  <at> _;
     return DECLINED unless $r->is_main;

     my $status = $r->last->status;
     return DECLINED unless $status == SERVER_ERROR;
     my $error = $r->notes('error-notes') || $ENV{ERROR_NOTES};
     return DECLINED unless $error;

     # create your email message and send it. I also like to put in a
     # Data::Dumper dump of %ENV, the URL, timestamp and other project
     # specific config settings

     return DECLINED;
}

--

-- 
Michael Peters
Plus Three, LP

Re: get backtrace emailed when code dies running under ModPerl::RegistryPrefork?

Michael Peters wrote:
> 
> You don't even need to use a __DIE__ handler. mod_perl will place any 
> runtime errors into $r->notes('error-notes'). I don't like my errors 
> going to the browser (only really works if your content is HTML anyway) 
> but for the email I usually use an Apache cleanup handler. That way it 
> gets sent after the client request has returned, so they don't have to 
> wait on it.
> 

This was news to me, so i went to the docs.  According to them, you have 
to explicitly enable this behavior.  see:

http://perl.apache.org/docs/2.0/api/Apache2/Log.html#C_Apache2__Const__LOG_TOCLIENT_

Is that still accurate?

Adam

Re: get backtrace emailed when code dies running under ModPerl::RegistryPrefork?

Adam Prime wrote:

> This was news to me, so i went to the docs.  According to them, you have 
> to explicitly enable this behavior.  see:
> 
> http://perl.apache.org/docs/2.0/api/Apache2/Log.html#C_Apache2__Const__LOG_TOCLIENT_ 
> 
> 
> Is that still accurate?

I don't know about mod_perl2, but I didn't have to do anything to have it 
enabled under mod_perl1.

--

-- 
Michael Peters
Plus Three, LP