Apache-Datei-Anforderungen und Analyse

469
steve

Ich bin gerade bei der Arbeit auf eine interessante Situation gestoßen, die mein Verständnis dafür, wie apache2 PHP-Dateien ausführt, in die Hölle brachte.

Ich hatte den Eindruck, dass apache2 den richtigen Dateityp ermitteln und durch den korrekten Dateiparser ausführen würde. Dies würde es dem Parser ermöglichen, die eigentliche Ausführung auszuführen, und aus diesem Grund war ich der Ansicht, dass die von Apache ausgeführten PHP-Dateien nur Leserechte benötigen.

Beispiel:

nimm eine einfache PHP-Datei mit 744-Rechten

#!/usr/bin/php <?php echo "test"; ?> 

Wird das mit ./test.php ausgeführt, wird eine Berechtigung abgelehnt.

Die Ausführung mit / usr / bin / php test.php funktioniert jedoch einwandfrei.

Ändern Sie die Rechte auf 755 und es wird korrekt mit ./test.php ausgeführt

Dies scheint das Gleiche zu sein, wenn Apache die Datei ausführt. Es wird ein verbotener Fehler zurückgegeben.

also endlich .. hier kommen die Fragen.

Wie behandelt Apache eigentlich Anforderungen für Dateien?

Wie übergibt sie die Datei an den richtigen Parser?

Warum braucht es Ausführungsrechte? Natürlich liest der Parser nicht nur die Datei, wie ich ursprünglich erwartet hatte.

Sei sanft, bitte ... ich dachte, ich kannte dieses Zeug.

0
Wem gehört die Datei, Sie, "root" oder der Apache-Benutzer (in der Regel "www-data")? Breakthrough vor 11 Jahren 0

1 Antwort auf die Frage

1
Rich Homolka

1) Die Ausführungs-Perms der Datei bedeuten für Apache nichts. Das bedeutet nur, dass der Kernel weiß, wie er die Datei ausführt, wenn Sie versuchen, sie auszuführen (zB über die Shell). Wenn Sie Dauerwellen gelesen haben, in denen Apache sie lesen kann, sind Sie in Ordnung.

BEARBEITEN Sie die Lese-Perms. Das Wichtigste ist, dass Apache Perms für die Verzeichnisse bis zum Stammverzeichnis ausführen muss. Ausführen bedeutet für ein Verzeichnis durchsuchbar, und Apache benötigt Suchberechtigungen für das Verzeichnis, um nach der Datei zu suchen.

2) Apache "gibt" die Dateien nicht ab. Es führt sie nicht aus. Sie haben einen eingebetteten Interpreter in Apache, der PHP-Dateien verarbeiten kann. Dies geschieht innerhalb des Apache-Prozesses. Es wird so konfiguriert:

Sie fügen das Modul hinzu:

LoadModule php5_module libexec/libphp5.so 

Das Modul wird kompiliert / erstellt, um zu wissen, wie mit dem Analysieren von PHP umzugehen ist. Es ist mit dem PHP-Interpreter verknüpft und besteht im Wesentlichen aus Glue-Code, damit PHP mit Apache in der von Apache erwarteten Art und Weise spricht. Das PHP-Modul weiß genau, wie mit zwei MIME-Typen umzugehen ist, application/x-httpd-phpund application/x-httpd-php-source. Jetzt müssen Sie Apache mitteilen, wie man PHP-Dateien mit dem Modul verbindet. Dies geschieht normalerweise mit:

<IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> 

Jetzt haben wir Apache angewiesen, PHP-Dateien an den PHP-Prozessor zu übergeben. Ist das Nachsilben der einzige Weg? Nein, Sie können alle Verzeichnisse so konfigurieren, dass sie alle PHP-Dateien oder den gesamten Server enthalten. Das macht aber am meisten Sinn. Beachten Sie auch, dass uns die Shebang-Linie (#! / Usr / bin / php) nicht wichtig ist. Wir sind nur für die Dateierweiterung konfiguriert.

3) OK, warum haben Sie den verbotenen Fehler? Ich weiß es nicht. Es kann viele Gründe dafür geben. Haben Sie das Fehlerprotokoll geprüft? Verfügen Sie über die richtigen Perms für das Dateisystemverzeichnis, in dem der Apache-Prozess Verzeichnisse bis zum Stammverzeichnis lesen kann? Hast du die richtigen Perms in den Konfigurationsdateien? Ich würde die Fehlerprotokolle überprüfen.

ZWEITER EDIT

Ich glaube, ich verstehe deine Verwirrung ...

Es gibt zwei Möglichkeiten, dynamischen Inhalt über Apache zu generieren. Einer ist durch einen eingebetteten Interpreter wie PHP. Perl und Python sind auch übliche eingebettete Interpreter. Der Webserver lädt den Interpreter mithilfe eines Glue-Moduls (mod_php, mod_perl usw.) in den httpd-Prozess. Der Code wird nicht "ausgeführt", sondern innerhalb des httpd-Prozesses geladen, analysiert und interpretiert.

Der zweite Weg führt über ein CGI-Skript. In diesem Fall Apache funktioniert die Datei auszuführen. In diesem Fall sind Umgebungsvariablen (Apache setzt einige Flags) und möglicherweise Standardeingaben für das Skript. Um an Apache zurückzusenden, senden Sie Inhalte standardmäßig heraus, wobei Apache leichte Dekorationen hinzufügt und an den Client sendet, und Sie senden Fehler an stderr, die an ihr error_log angehängt werden. Die CGI-Spezifikation gibt die Regeln vor, wie dieser "Kleber" funktioniert. In diesem Fall führen Sie eine Datei aus, daher sind die Ausführungsberechtigungen für die Datei für Apache wichtig.

CGI ist weniger verbreitet als früher. Die Vorteile von CGI sind, dass es sich um einen vom Webserver isolierten Prozess handelt. Es kann keinen Schaden anrichten (gut, solange die Ausgabe sicher analysiert wird). Die Nachteile sind die Isolation. Ich muss für jeden Durchlauf eine Fork / exec ausführen (obwohl es einige Schemas gibt, die fastCGI genannt werden, die dies unterstützen). PHP (unter einigen anderen) hat auch ein anderes Codierungsmodell, bei dem Sie HTML etwas Code hinzufügen, anstatt ein großes Skript zu schreiben und von dort aus HTML auszutauschen. Dies macht es für die meisten Leute einfacher, zu schreiben, weshalb PHP im Web so beliebt ist.

Das macht Sinn. Was ich nicht verstehe, ist der verbotene Fehler. Berechtigungen wurden rekursiv durch das Verzeichnis 744. Ich musste es tatsächlich auf 755 setzen, bevor es funktionierte. steve vor 11 Jahren 0
@steve Wenn die DIRECTORY-Perms kein Ausführungsbit haben, gibt es ein Problem beim 'Durchsuchen' von Dateien. Dann konnte ich Ihr Problem sehen, Apache konnte die Datei aufgrund von Verzeichnis-Perms nicht finden. Die Dateibewegungen müssen nur lesbar sein. Rich Homolka vor 11 Jahren 1
@steve Ha, danke, aber nicht so sicher. war schon eine Weile da. Ich verwende Apache seit 1996 oder so, möglicherweise etwas früher. Installation von Webservern im Allgemeinen seit 1993. Rich Homolka vor 11 Jahren 0