Hallo Manfred.
Am 3. Februar 2009 07:04 schrieb Manfred Rebentisch <mrebenti...@comparat.de>:
> Bei der URI
>        r->uri: [/gruenkohl/gruenkohl.html]
> gibt es ein PATH_INFO:
>        r->path_info: [/gruenkohl.html]
>
>        r->finfo.protection: 1877 (0x755),
>        r->used_path_info: 2  (AP_REQ_DEFAULT_PATH_INFO)
>        r->finfo.filetype: 0 (no filetype determined)
>
> Wenn ich eine URI verwende, wo der Pfad existiert, aber die Datei nicht, sind
> die Werte die gleichen, aber path_info ist leer und
>        r->finfo.filetype: 0 (no filetype determined)
>
> Wenn auch die Datei im Filesystem existiert, hat finfo.protection den Wert:
>        r->finfo.protection: 1604 (0x644)
> und
>        r->finfo.filetype: 1 (regular file)
>
> Ich kann also zusammenfassen und bei gesetzter Einstellung
> mit "ModMimeUsePathInfo on" r->finfo.filetype auf 0 prüfen und path_info auf
> nicht leer: dann habe ich ein Verzeichnis, das nicht existiert.

Ja, das wäre auch der Fall ohne 'ModMimeUsePathInfo on', nur dass dann
dein Handler nicht über Addhandler zugewiesen werden würde. Zunächst
wird in der translate_name-Phase der Request auf einen r->filename
übersetzt, z.B. bei r->uri /verfahren/eins/zwei/drei/glossar.html in
r->filename /var/www/cpweb09/verfahren/eins/zwei/drei/glossar.html. In
der map_to_storage-Phase wird mit diesem r->filename dann der
directory_walk durchgeführt. Das geht dann Verzeichnisebene für
Verzeichnisebene vom Wurzelverzeichnis aus. Hier werden auch die
.htaccess-Dateien gelesen. All das, was vom r->filename noch nicht
Verzeichnis für Verzeichnis durchlaufen wurde, ist path-info. Kommt
der directory_walk nun an einem Punkt an, wo ein Verzeichnis nicht
mehr existiert, bricht er ab. Das letzte nicht-existierende
Verzeichnis wird dann als Datei behandelt, die natürlich auch
tatsächlich existieren kann (hier verfahren), r->filename bleibt also
bei /var/www/cpweb09/verfahren. Der nicht durchlaufene Rest bleibt
path-info (/eins/zwei/drei/glossar.html).

> Die r->uri [/verfahren/eins/zwei/drei/glossar.html] wird aufgesplittet in ,
> r->path_info: [/eins/zwei/drei/glossar.html], und r->filename:
> [/var/www/cpweb09/verfahren]
> das heißt, wenn finfo.filetype auf 0 steht, steht in filename der erste nicht
> existierende Pfad.

Genau.

> Warum ist r->used_path_info immer auf 2  (AP_REQ_DEFAULT_PATH_INFO)?

Das ist der Standardwert der Direktive AcceptPathinfo.

> Welche sicherheitsrelevanten Auswirkungen hat das noch?

Das obliegt dem content handler. Die Direktive findet vor den content
handlern glaube ich nur bei mod_speling in der fixup-Phase
Berücksichtigung. Anhand der Auswertung von r->used_path_info kann der
content handler sein Verhalten abweichend von seinem sonstigen
Standardverhalten festlegen. Nehmen wir bspw. den core content
handler. Dieser weist den request mit einem 404 standardmäßig ab, wenn
path-info vorhanden ist. Hat r->used_path_info den Wert
AP_REQ_ACCEPT_PATH_INFO (war das 0?), dann würde der core content
handler den Request nicht abweisen. Umgekehrt bei mod_php oder
mod_cgi: Diese Handler akzeptieren standardmäßig path-info. Steht
r->used_path_info auf AP_REQ_REJECT_PATH_INFO, so geben sie einen 404
zurück. Es obliegt also immer dem content handler, zu entscheiden, was
passieren soll. Wertet der content handler r->used_path_info nicht
aus, dann fährt er eben immer sein "fest gecodetes" Standardverhalten;
da kann der Benutzer dann noch so viel an AcceptPathinfo
konfigurieren, wie er will.

Sollten noch statische Dateien über den core-Handler ausgeliefert
werden, sollte AcceptPathinfo nicht verändert werden. Da dein Handler
nicht dateisystembasiert arbeitet (du wertest r->uri aus?), sollte
diesem path-info egal sein.

Bob

--------------------------------------------------------------------------
                Apache HTTP Server Mailing List "users-de"
      unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org
           sonstige Anfragen an users-de-h...@httpd.apache.org
--------------------------------------------------------------------------

Antwort per Email an