Что вызывает “нарушение политики suexec”, когда Perl вызывается через серверную часть include?

Question

Я работаю над скриптом Perl, который вызывается со стороны сервера include на сервере Apache 2.Скрипт отображает общую страницу "Внутренняя ошибка сервера", а не показывает мне фактическую ошибку.Когда я проверяю журнал ошибок Apache, я вижу эти сообщения:

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/

Как мне заставить Perl-скрипт показывать ошибку, а не "Внутреннюю ошибку сервера"?

Обновить:

Мне следовало бы задать по этому поводу отдельный вопрос, потому что с тех пор я узнал, что это делает отправлять ошибки в браузер (спасибо, Брайан):

use CGI::Carp qw(fatalsToBrowser);

Однако, если проблема связана с конфигурацией Apache, а не со скриптом Perl, то ошибка не будет отправлена в браузер, поскольку код Perl не интерпретируется.В этом случае мы можем сказать, что я испытываю ошибку Apache (а не ошибку Perl) из-за этой строки:

 suexec policy violation: see suexec log for more details

Это происходит, когда Apache работает в режиме SUexec (который, по-видимому, является обычным для общего хостинга).Я не уверен, что именно было изменено, чтобы вызвать эту ошибку, но это то, что я пытаюсь выяснить.

Answer 1

Вероятно, вы используете виртуальный хостинг и у вас возникла эта проблема, потому что ваш каталог сценариев или файл сценария имеет другие права, кроме 755.

Вот один случай перевод с голландского.

Answer 2

Использовать CGI::Карп's fatalsToBrowser.

 use CGI::Carp qw(fatalsToBrowser);

Возможно, вы также захотите увидеть мой Устранение неполадок в сценариях Perl CGI.

Судя по сообщению об ошибке, я предполагаю, что вам не разрешено выполнять сценарии CGI со стороны сервера.Какую версию Apache вы используете?Если это старый Apache, см. документация suexec для apache 1.3, или, если это более новая версия Apache, см. документация suexec для Apache 2.0.

Answer 3

Мы не показываем пользователям точную ошибку не для удобства использования, а часто для безопасности, когда пользователь ничего не может с этим поделать.Например, представьте, что внутренний сервер недоступен.Что я, как пользователь, могу сделать, чтобы исправить это в вашем веб-приложении?

В некоторых случаях сообщения об ошибках будут содержать полезную информацию, например "Ошибка SQL:недопустимый синтаксис.Непревзойденный"".Если бы пользователь ввел цитату в свои входные данные, этот отзыв указывал бы на уязвимость SQL-инъекции.

Другие безобидно выглядящие сообщения также нежелательно показывать пользователям.Главное, чего хочет злоумышленник, - это знать, что "произошло что-то другое". Если приложение выводит одну ошибку для одного ввода и другую ошибку для другого ввода, то злоумышленник знает, что что-то пошло не так, и что это интересное место для фокусировки.

На производственном сайте ошибки должны регистрироваться в файле и, при необходимости, загружаться через ваш веб-интерфейс, но будьте очень осторожны при обработке любых выходных данных в браузере, чтобы избежать межсайтового скриптинга.И не должно быть предоставленной пользователем опции для перенастройки этого между отладкой и производством (не управляйте этим с помощью параметра POST или CGI, а с помощью опции файла конфигурации).

Answer 4

Это может быть 3 фактора:

1. Неверно установлен уровень разрешений rwx (уровень выполнения/записи)
2. UUID/GUID не соответствуют настройкам Apache.
3. Комбинация двух вышеперечисленных.

Подробности проверьте apache suexec+errorlog.