Was sind die Ursachen „suexec Richtlinienverletzung“, wenn Perl genannt wird über Server-Seite enthalten?

Question

Ich arbeite an einem Perl-Skript, das von einer Server-Seite aufgerufen wird, ist auf einem Apache-2-Server. Das Skript wird die Anzeige der generische „Internal Server Error“ Seite anstatt mir den tatsächlichen Fehler zeigt. Wenn ich das Fehlerprotokoll Apache überprüfen, sehe ich diese Meldungen:

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/

Wie erhalte ich einen Perl-Skript einen Fehler zu zeigen und nicht als "Internal Server Error"?

Update:

Ich habe eine andere Frage darum gebeten sollte, weil ich da gelernt haben, dass diese hat Sendefehler an den Browser ( dank brian ):

use CGI::Carp qw(fatalsToBrowser);

Wenn jedoch das Problem mit der Konfiguration von Apache ist nicht der Perl-Skript, dann wird der Fehler nicht an den Browser gesendet werden, weil der Perl-Code wird nicht interpretiert werden. In diesem Fall können wir sagen, dass ich einen Apache-Fehler erlebt (eher als ein Fehler Perl) wegen dieser Zeile:

 suexec policy violation: see suexec log for more details

Dies geschieht, wenn Apache ist in suEXEC-Modus ausgeführt wird (was für gemeinsam zu sein scheint Shared-Hosting). Ich bin sicher nicht, was genau geändert wurde, um diesen Fehler zu verursachen, aber das ist, was ich versuche heraus zu finden.

Answer 1

Wahrscheinlich sind Sie mit Shared-Hosting und Sie haben dieses Problem, weil die scripts oder Skript-Datei hat andere Rechte als 755.

Hier ist ein Fall aus dem niederländischen übersetzt.

Answer 2

Verwenden Sie CGI :: Carp 's fatalsToBrowser.

 use CGI::Carp qw(fatalsToBrowser);

Sie können auch sehen wollen, meine Fehlerbehebung Perl-CGI-Skripte .

Von der Fehlermeldung, ich nehme an, dass Sie nicht CGI dürfen Skripte ausgeführt werden von Server-Seite enthält. Welche Version von Apache sind Sie? Wenn es ein alter Apache finden Sie unter die suexec Dokumentation für Apache 1.3 , oder wenn es ist ein neuer Apache finden sie unter die suexec Dokumentation für Apache 2.0 .

Answer 3

Es ist nicht für die Benutzerfreundlichkeit, aber oft für die Sicherheit, dass wir nicht zeigen Benutzer die genauen Fehler, wenn der Benutzer nichts dagegen tun können. Zum Beispiel vorstellen, dass ein Back-End-Server ist nicht verfügbar. Was kann ich als Anwender, um fix zu tun, dass in Ihrer Web-Anwendung?

In einigen Fällen Fehlermeldungen werden nützliche Informationen enthalten, wie „SQL-Fehler:. Illegale Syntax Unübertroffene '“. Wenn die Benutzereingabe in ihrem Eingang ein Angebot hat, dieses Feedback würde eine SQL-Injection-Schwachstelle an.

Andere gutartige suchen Nachrichten sind schlecht für die Nutzer zu zeigen, wie gut. Der Schlüssel ist daran, dass der Angreifer will, ist zu wissen, „etwas anderes passiert ist.“ Wenn die Anwendung druckt ein Fehler für einen Eingang und einen anderen Fehler für einen anderen iInput, dann weiß der Angreifer, dass etwas anderes schief gegangen ist, und dass dies ein interessanter Ort zu konzentrieren.

In einer Produktionsstätte, soll Fehler-Datei protokolliert werden, und gegebenenfalls zum Download über Ihr Web-Interface - aber sehr vorsichtig sein, jede Ausgabe an den Browser zu sanieren Cross-Site-Scripting zu vermeiden. Und es sollte keine Benutzer übermittelten Option, dies zu rekonfigurieren zwischen Debug- und Produktion (keine Kontrolle über sie über einen POST oder CGI-Parameter, sondern durch eine Konfigurationsdatei-Option).

Answer 4

Diese 3 Faktoren sein könnte:

1. Berechtigungsstufe rwx Satz falsch (Ausführung / writeness Ebene)
2. UUID / GUID nicht Apache Einstellungen übereinstimmen
3. Die Kombination von 2 oben.

Überprüfen Sie Apache suexec + errorlog für Details