Что включают причины “suexec нарушение политики”, когда Perl называют через сторону сервера?
Я работаю над сценарием Perl, который называют от стороны сервера, включают в сервер Apache 2. Сценарий отображает универсальную страницу "Internal Server Error" вместо того, чтобы показать мне фактическую ошибку. Когда я проверяю журнал ошибок 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 показывать ошибку, а не "Внутреннюю Ошибку Сервера"?
Обновление:
Я должен был задать отдельный вопрос для этого, потому что я с тех пор узнал, что это действительно отправляет, ошибки к браузеру (благодарит brian):
use CGI::Carp qw(fatalsToBrowser);
Однако, если проблема будет с конфигурацией Apache, а не сценарием Perl, то ошибка не будет отправлена в браузер, потому что код Perl не интерпретируется. В этом случае мы можем сказать, что я сталкиваюсь с ошибкой Apache (а не ошибкой Perl) из-за этой строки:
suexec policy violation: see suexec log for more details
Это происходит, когда Apache работает в режиме SUexec (который, кажется, характерен для общего хостинга). Я не уверен, что точно было изменено для порождения этой ошибки, но это - то, что я пытаюсь узнать.
3 ответа
Вероятно, вы используете общий хостинг, и у вас есть эта проблема, потому что ваш каталог сценариев или файл сценария имеют другие права, кроме 755 .
Вот один случай в переводе с голландского.
Используйте CGI :: Carp fatalsToBrowser .
use CGI::Carp qw(fatalsToBrowser);
Возможно, вы также захотите увидеть мои Устранение неполадок в сценариях Perl CGI .
Судя по сообщению об ошибке, я предполагаю, что вам не разрешено выполнять сценарии CGI со стороны сервера. Какую версию вашего Apache вы используете? Если это старый apache, см. документацию suexec для apache 1.3 , а если это более новый apache, см. документацию suexec для apache 2.0 .
Мы не показываем пользователям точную ошибку, когда пользователь ничего не может с этим поделать, но не для удобства пользователя, а для обеспечения безопасности. Например, представьте, что внутренний сервер недоступен. Что я, как пользователь, могу сделать, чтобы исправить это в вашем веб-приложении?
В некоторых случаях сообщения об ошибках будут содержать полезную информацию, например «Ошибка SQL: недопустимый синтаксис. Несовпадение». Если бы пользователь ввел цитату в свой ввод, эта обратная связь указала бы на уязвимость SQL-инъекции.
Другие безобидные сообщения также не могут быть показаны пользователям. Главное, чего хочет злоумышленник, - это знать, что «произошло что-то другое». Если приложение выводит одну ошибку для одного входа и другую ошибку для другого iinput, то злоумышленник знает, что что-то другое пошло не так, и что это интересное место для сосредоточения.
На рабочем сайте ошибки должны регистрироваться в файле и, при необходимости, загружаться через ваш веб-интерфейс, но будьте очень осторожны, очищая любой вывод в браузере, чтобы избежать межсайтового скриптинга. И не должно быть отправленных пользователем параметров для перенастройки этого между отладкой и производством (не управляйте им с помощью параметра POST или CGI, а с помощью параметра файла конфигурации).