What causes "suexec policy violation" when Perl is called via server side include?

Question

I'm working on a Perl script which is called from a server side include on an Apache 2 server. The script is displaying the generic "Internal Server Error" page rather than showing me the actual error. When I check the Apache error log, I see these messages:

unable to include "/foobar/index.pl" in parsed file /home/foouser/domains/foosite.com/public_html/foobar/index.shtml, referer: http://www.foosite.com/foobar/
suexec policy violation: see suexec log for more details, referer: http://www.foosite.com/foobar/
Premature end of script headers: settings.pl, referer: http://www.foosite.com/foobar/

How do I get a Perl script to show an error rather than "Internal Server Error"?

Update:

I should have asked a separate question for this, because I have since learnt that this does send errors to the browser (thanks brian):

use CGI::Carp qw(fatalsToBrowser);

However, if the problem is with the Apache config rather than the Perl script, then the error will not be sent to the browser because the Perl code is not being interpreted. In this case, we can tell that I am experiencing an Apache error (rather than a Perl error) because of this line:

 suexec policy violation: see suexec log for more details

This occurs when Apache is running in SUexec mode (which seems to be common for shared hosting). I'm not sure what exactly has been changed to cause this error, but that's what I'm trying to find out.

Answer 1

Use CGI::Carp's fatalsToBrowser.

 use CGI::Carp qw(fatalsToBrowser);

You might also want to see my Troubleshooting Perl CGI scripts.

From the error message, I'm guessing that you aren't allowed to execute CGI scripts from server side includes. Which version of your Apache are you running? If it's an old apache, see the suexec docs for apache 1.3, or if it's a newer apache, see the suexec docs for apache 2.0.

Answer 2

Probably you are using shared hosting and you have this problem because your scripts directory or the script file does have other rights than 755.

Here is one case translated from Dutch.

Answer 3

It's not for user friendliness, but often for security that we don't show users the exact error when the user can't do anything about it. For example, imagine that a back end server is unavailable. What can I, as a user, do to fix that in your web application?

In some cases, error messages will contain useful information, like "SQL Error: illegal syntax. Unmatched ' ". If the user had input a quote in their input, this feedback would indicate a SQL injection vulnerability.

Other benign looking messages are bad to show to users, as well. The key thing that the attacker wants is to know "something different happened." If the application prints out one error for one input,and another error for another iinput, then the attacker knows that something different has gone wrong, and that this is an interesting place to focus.

In a production site, errors should be logged to file, and, if appropriate, downloadable through your web interface - but be very careful to sanitize any output to the browser to avoid cross site scripting. And there should be no user-submitted option to reconfigure this between debug and production (don't control it via a POST or CGI parameter, but by a configuration file option).