AuthUserFile

[Joe]

Hallo

Nur kurz gefragt, ich hab schon gesucht und nichts gefunden:

Was passiert wenn in einem Ordner folgende .htaccess liegt?

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName DenyViaWeb
AuthType Basic

<Limit GET>
order allow,deny
deny from all
</Limit>

Insbesondere würde ich gern wissen, was die beide /dev/null da machen bzw. welche Wirkung da vom Apache noch übrig bleibt - keine?

Warum macht man das?

Joe

[wahsaga]

hi,

Was passiert wenn in einem Ordner folgende .htaccess liegt?

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName DenyViaWeb
AuthType Basic

<Limit GET>
order allow,deny
deny from all
</Limit>

Insbesondere würde ich gern wissen, was die beide /dev/null da machen bzw. welche Wirkung da vom Apache noch übrig bleibt - keine?

Nutzername und Passwort in /dev/null zu suchen, wird zu keinem Ergebnis führen - also kann sich niemand authentifizieren, egal mit welchen Daten.
Auch der AuthName DenyVieWeb spricht ja schon dafür, dass da jemand gar nicht will, dass über HTTP zugegriffen werden kann.

Nur ist das irgendwie überflüssig - mit dem Deny from all werden solche Anfragen sowieso abgeschmettert, im Beispiel allerdings nur für die Methode GET. Das hätte man aber genauso gut für allem machen können, und sich den Auth-Kram dann sparen, wenn es nur darum geht, über HTTP keinen Zugriff zu erlauben.

Warum macht man das?

Schräger Humor?

gruß,
wahsaga

[_roro]

hi,

Warum macht man das?

Schräger Humor?

Oder ne Prüfungsfrage.

--roro

[Christoph Schnauß]

hallo Joe,

Was passiert wenn in einem Ordner folgende .htaccess liegt?

Nichts, was irgendeinen sichtbaren Effekt hätte. Du erzeugst etwas unnötige Serverlast. Und niemand bekommt Zutritt zu deinem Ordner.

Insbesondere würde ich gern wissen, was die beide /dev/null da machen

/dev/null ist das allgemeine Nirwana. Deine .htaccess sucht dort, wo es "nichts" gibt, nach Autorisierungsangaben. Es gibt keine.

<Limit GET>
order allow,deny
deny from all
</Limit>

Das ist ein allgemeines Verbot für alles, was über GET verlangt wird.

Warum macht man das?

Frag denjenigen, der diese .htaccess geschrieben hat und einsetzt. "Man" sollte sowas nicht machen.

Grüße aus Berlin

Christoph S.

[Joe]

Hallo Christoph (auch an die anderen die geantwortet haben Hallo)

Nichts, was irgendeinen sichtbaren Effekt hätte. Du erzeugst etwas unnötige Serverlast. Und niemand bekommt Zutritt zu deinem Ordner.

Danke für die Bestätigung meiner Gedanken.

/dev/null ist das allgemeine Nirwana. Deine .htaccess sucht dort, wo es "nichts" gibt, nach Autorisierungsangaben. Es gibt keine.

Deshalb fragte ich mich auch was das soll!

<Limit GET>
order allow,deny
deny from all
</Limit>
Das ist ein allgemeines Verbot für alles, was über GET verlangt wird.

Mhm. also in /cgi-bin/irgenwas/script.pl ist der benutzende Script
und in /cgi-bin/irgenwas/nochwas/.htaccess liegen teils Daten teils zu requirende Scriptteile

Kann denn der aufgerufene Script in den Ordner greifen und holen, was er braucht und schreiben was er will?

Dann könnte die Sache doch Sinn machen. Der Script kann ohne Passwort aufgerufen werden es gibt aber ein login und es sieht so aus, als ob die Passwörter und Benutzernamen in Cookies gehandelt werden.

Von Außen kann indi* dann nicht in die Ordner greifen und der Script könnte das dann.

Immer vorrausgesetzt der Gedanke ist richtig, das der Script selbst nicht als fremder Zugriff gewertet wird.

Gehe ich wohl recht in meiner Annahme?

Joe

[Christoph Schnauß]

hallo,

Mhm. also in /cgi-bin/irgenwas/script.pl ist der benutzende Script

Nicht "der", sondern "das" Script. Warum in einem Unterverzeichnis von cgi-bin?

und in /cgi-bin/irgenwas/nochwas/.htaccess liegen teils Daten teils zu requirende Scriptteile

Das ist wenig sinnvoll. Man nennt ein "Verzeichnis" nicht ".htaccess". Abgesehen davon, daß der Punkt vor diesem Verzeichnisnamen es als "versteckt" kennzeichnen würde.

Kann denn der aufgerufene Script in den Ordner greifen und holen, was er braucht und schreiben was er will?

Selbstverständlich, solange es sich um _das_ Script handelt. Wie die Verzeichnisse heißen, ist wurscht. Solange das Script den korrekten Verzeichnisnamen kennt.

Dann könnte die Sache doch Sinn machen.

Erst dann, wenn du verrätst, wo nun deine _Datei_ .htaccess liegt.

Der Script kann ohne Passwort aufgerufen werden es gibt aber ein login und es sieht so aus, als ob die Passwörter und Benutzernamen in Cookies gehandelt werden.

Das tut es zwar nicht, spielt aber keine Rolle. Es ist schlichtweg Verarschung, was da passiert.

Gehe ich wohl recht in meiner Annahme?

Nein. Du gehst Kurven.

Grüße aus Berlin

Christoph S.

[Joe]

und in /cgi-bin/irgenwas/nochwas/.htaccess liegen teils Daten teils zu requirende Scriptteile

Das ist wenig sinnvoll. Man nennt ein "Verzeichnis" nicht ".htaccess". Abgesehen davon, daß der Punkt vor diesem Verzeichnisnamen es als "versteckt" kennzeichnen würde.

.htaccess ist ja auch kein Ordner Ordner haben bei mir um sie nicht explizit benennen zu müssen immer ein / am ende :-)
script.pl ist auch kein Ordner sondern DAS Script.

Erst dann, wenn du verrätst, wo nun deine _Datei_ .htaccess liegt.

done

Das tut es zwar nicht, spielt aber keine Rolle. Es ist schlichtweg Verarschung, was da passiert.

Das glaube ich nicht.

Das Script ist ein Forum-Script das einmal recht weit verbreitet war.
Und wie ich meiner eigenen Vermutung nach gehe, stelle ich fest, das tatsächlich sowohl Passwort als auch Benutzername in den Cookies stecken.

Also meinst du immer noch das ist Verarschung?

Wenn ja warum?

Joe

[wahsaga]

hi,

Das Script ist ein Forum-Script das einmal recht weit verbreitet war.
Und wie ich meiner eigenen Vermutung nach gehe, stelle ich fest, das tatsächlich sowohl Passwort als auch Benutzername in den Cookies stecken.

Die Cookies können stecken haben, was sie wollen - wenn über DENY der HTTP-Zugriff verboten ist, dann ist kein HTTP-Zugriff möglich (in diesem Falle zumindest über GET).

gruß,
wahsaga

[wahsaga]

Nachtrag:

Die Cookies können stecken haben, was sie wollen - wenn über DENY der HTTP-Zugriff verboten ist, dann ist kein HTTP-Zugriff möglich (in diesem Falle zumindest über GET).

Wegen der durch
order allow,deny
vorgegebenen Priorität könnte in diesem Falle allerdings ein ALLOW aus übergeordneten Ebenen zum Zuge kommen. Aber davon wissen wir aktuell nichts.

gruß,
wahsaga

[Joe]

Hallo @wahsaga

Die Cookies können stecken haben, was sie wollen - wenn über DENY der HTTP-Zugriff verboten ist, dann ist kein HTTP-Zugriff möglich (in diesem Falle zumindest über GET).

Klar was den Apache betrifft, aber das war ja auch nur Kontext-Info. Ich wollte damitsagen, das die Authentifizierung vom Script selbst übernommen wird. Der Sinn ist wohl das der gleiche scriptaufruf einmal mit und auch ohne Passwort funktionieren sollte und das kann durch Apache mit .htaccess nicht erreicht werden.

Wegen der durch
order allow,deny
vorgegebenen Priorität könnte in diesem Falle allerdings ein ALLOW aus übergeordneten Ebenen zum Zuge kommen. Aber davon wissen wir aktuell nichts.

Weder in /cgi-bin/ noch in /cgi-bin/irgendwas/ ist eine .htaccess

Also übergeordnet wäre dann ja nur noch die httpd.conf

Übrigens, ich bin Admin-c deshalb darf ich im cgi-bin rummachen. Und wenn ich was installiere muß ich wissen wie es geht. Und wo die Grenzen der Sicherheit sind.

Nochmal zu meiner Frage die vielleicht Licht bringt:

Wenn eine Scriptausführung durchgeführt wird, Dann ist doch der Apache in diesem Moment an der Überwachung der Ordner garnicht mehr beteiligt. Praktisch könnte der Script auch auf Bereiche außerhalb der documentroot zugreifen, soweit es der Rechneradmin zuläßt und auch innerhalb der documentroot ist das nur von den Dateirechten abhängig und nicht vom Apache. Wenn das Script eine Redirektion durchführen würde, käme doch erst der Apache wieder ins Spiel.
Ich habe das Gefühl ich übersehe was, aber was?

Zusammengefasst:
Wenn ich richtig liege, sollen die untergeordneten Verzeichnisse vor Zugriffen von Außen geschützt werden und sollen dennoch in der documentroot hängen, möglicherweise wegen der Beschränkungen auf großen Server-Farmen. Würden die Daten außerhalb der dokumentroot gespeichert bräuchte indi das .htaccess nicht. So aber werden die Daten ja geschützt und wenn ich es richtig verstehe, stehen sie dem Script jederzeit zur Verfügung. Da der Script den Zugriff von sich aus regelt, deshalb cooki-Passwörter, weis schlieslich der Script wer was bekommen darf.

Joe

[Christoph Schnauß]

hallo,

Also übergeordnet wäre dann ja nur noch die httpd.conf

Nein. Übergeordnet ist die DocumentRoot, also /

Wenn eine Scriptausführung durchgeführt wird, Dann ist doch der Apache in diesem Moment an der Überwachung der Ordner garnicht mehr beteiligt.

Richtig.

Praktisch könnte der Script auch auf Bereiche außerhalb der documentroot zugreifen

Nein. Aber _das_ Script könnte das, und genau das ist auch der Grund, weshalb manche Provider keine Ausführung eigener Scripts zulassen.

Wenn das Script eine Redirektion durchführen würde, käme doch erst der Apache wieder ins Spiel.

Wenn der redirect auf einen nderen Server führt, muß dort ja nicht zwingend auch der Apache vorausgesetzt werden.

Wenn ich richtig liege, sollen die untergeordneten Verzeichnisse vor Zugriffen von Außen geschützt werden und sollen dennoch in der documentroot hängen

Da geht was durcheinander. "untergeordnete Verzeichnisse" hängen immer unterhalb der DocumentRoot, sofern sie denn über HTTP angesprochen werden sollen.

Würden die Daten außerhalb der dokumentroot gespeichert bräuchte indi das .htaccess nicht.

Es gibt in der Apache-Doku ausdrücklich die Empfehlung, Dateien mit Benutzerinformationen (AuthUserFile) _außerhalb_ der DocumentRoot anzulegen. /dev/null liegt zwar außerhalb, ist aber unsinnig.

So aber werden die Daten ja geschützt

Nein. Sie sind gar nicht erst vorhanden, da nach ihnen in /dev/null gesucht wird. Das meinte ich mit Verarschung.

Grüße aus Berlin

Christoph S.

[Joe]

Also übergeordnet wäre dann ja nur noch die httpd.conf

Nein. Übergeordnet ist die DocumentRoot, also /

Und die Direktive dazu steht in der httpd.conf und NICHT in einer /.htaccess -Datei

Wenn das Script eine Redirektion durchführen würde, käme doch erst der Apache wieder ins Spiel.

Wenn der redirect auf einen nderen Server führt, muß dort ja nicht zwingend auch der Apache vorausgesetzt werden.

Momentmal Apache bommt eine Anforderung den Script auszuführen kann er nicht wenn es perlist und kein MOD installiert. Also ruft er den Perl-interpreter auf. Von dem bekommt er zuerst die Redirektion oder einen anderen Output zurück über den STDOUT.
Was macht der Apache dann mit der Redirektion gibt er die an den Client weiter oder versucht er die neue Anforderung direkt an einen anderen Server weiterzugeben (Vorausgesetzt in der URI ist nicht der eigene Server gemeint)

Wenn ich richtig liege, sollen die untergeordneten Verzeichnisse vor Zugriffen von Außen geschützt werden und sollen dennoch in der documentroot hängen
Da geht was durcheinander. "untergeordnete Verzeichnisse" hängen immer unterhalb der DocumentRoot, sofern sie denn über HTTP angesprochen werden sollen.

Ok, präziser ausdrücken ist bei dir angesagt ich weis.
Das Original hat die Daten in Unterordnern des Ordners indem auch der Script läuft.
Die Daten die in diesen Ordnern sind könnten doch auch außerhalb der documentroot in Ordner (aller Wahrscheinlichkeit nach sind das auch Unterordner, denn sie werden ja wohl kaum als Top-Level-Ordner angelegt sein) gelegt werden und brauchen, weil dort ja kein Zugriff von Außen möglich ist nicht mit ".htaccess" "geschützt" werden.

Besser?

Es gibt in der Apache-Doku ausdrücklich die Empfehlung, Dateien mit Benutzerinformationen (AuthUserFile) _außerhalb_ der DocumentRoot anzulegen. /dev/null liegt zwar außerhalb, ist aber unsinnig.

:-)

So aber werden die Daten ja geschützt
Nein. Sie sind gar nicht erst vorhanden, da nach ihnen in /dev/null gesucht wird. Das meinte ich mit Verarschung.

Ich spreche hier von Daten nicht von Authentifizierungs-Daten ok  :-) und die werden geschützt, weil sie nicht mehr innerhalb der documentroot liegen. Ganz nach dem Vorbild der Authentifizierungsdaten.

Apache hat in diesem Fall mit Authentifizierung des Logins nichts zu tun, sondern mit der Anfangs geposteten .htaccess werden nur Daten geschützt vor sämtlichen Zugriff von Außen anscheinend aber nicht vor dem Script selbst, der benutzt die nämlich. :-)

Trotzdem dir und vor allem auch @wahsaga danke, das ihr Spiegel für meine Gedanken wart.
Ich glaube ich weis jetzt, warum und wieso, und es gefällt mir nicht sonderlich.
Vielleicht gelingt es mir die Sourcen so umzustricken, das sie ihre Daten von außerhalb der documentroot beziehen und ablegen. Das spart dann auch den Performance-Verlust wieder ein.

Joe

[Christoph Schnauß]

hallo Joe,

Nein. Übergeordnet ist die DocumentRoot, also /
Und die Direktive dazu steht in der httpd.conf und NICHT in einer /.htaccess -Datei

Was haben Direktiven mit der Verzeichnisstrutur zu tun? Und deine Ausgangsfrage ging ausdrücklich nach einer .htaccess - jetzt also nicht mehr?

Momentmal Apache bommt eine Anforderung den Script auszuführen kann er nicht wenn es perlist und kein MOD installiert.

Apache bekommt niemals eine Aufforderung, irgendein Script auszuführen. Das kann er nicht. Er kann aber aufgrund einer Anfrage vergleichen, ob in seiner Konfiguration vorgesehen ist, welcher "Partner" (beispielsweise Perl) ein Script ausführen dürfte, und dem dann das Script zur gefälligen Abarbeitung übergeben. Was du jetzt mit MOD meinst, ist mir unklar. Um den Perl-Interpreter um die Ausführung irgendeines Scripts zu bitten, muß der Apache überhaupt nix von irgendeinem mod_* wissen.

Also ruft er den Perl-interpreter auf. Von dem bekommt er zuerst die Redirektion oder einen anderen Output zurück über den STDOUT.

STDOUT? Wie sollte Apache damit umgehen?

Was macht der Apache dann mit der Redirektion gibt er die an den Client weiter

Falls wir jetzt unter "redirection" dasselbe verstehen: ja.

Das Original hat die Daten in Unterordnern des Ordners indem auch der Script läuft.

Da gehören sie nicht hin.

Die Daten die in diesen Ordnern sind könnten doch auch außerhalb der documentroot in Ordner (aller Wahrscheinlichkeit nach sind das auch Unterordner, denn sie werden ja wohl kaum als Top-Level-Ordner angelegt sein) gelegt werden und brauchen, weil dort ja kein Zugriff von Außen möglich ist nicht mit ".htaccess" "geschützt" werden.
Besser?

Nö ;-)

So aber werden die Daten ja geschützt
Nein. Sie sind gar nicht erst vorhanden, da nach ihnen in /dev/null gesucht wird. Das meinte ich mit Verarschung.
Ich spreche hier von Daten nicht von Authentifizierungs-Daten ok  :-) und die werden geschützt, weil sie nicht mehr innerhalb der documentroot liegen. Ganz nach dem Vorbild der Authentifizierungsdaten.

Dann werden sie nicht geschützt, sondern sind schlichtweg nicht erreichbar.

Apache hat in diesem Fall mit Authentifizierung des Logins nichts zu tun, sondern mit der Anfangs geposteten .htaccess werden nur Daten geschützt vor sämtlichen Zugriff von Außen

Ich dachte, das wäre genügend dargestellt. Es wird gar nichts geschützt. Es wird Schabernack getrieben.

anscheinend aber nicht vor dem Script selbst, der benutzt die nämlich. :-)

_das_ Script kann nichts benutzen, was nicht existiert. In /dev/null existiert nichts.

Grüße aus Berlin

Christoph S.

[Joe]

hallo Christoph

Was haben Direktiven mit der Verzeichnisstrutur zu tun? Und deine Ausgangsfrage ging ausdrücklich nach einer .htaccess - jetzt also nicht mehr?

Du bist wirklich nicht gerade Fehlertollerant.
Ok es sind nicht Direktiven ich meine das:
 <Directory />
    Options SymLinksIfOwnerMatch
    AllowOverride None
</Directory>

<Directory /var/www/>
    Options Indexes Includes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Momentmal Apache bekommt eine Anforderung den Script auszuführen kann er nicht wenn es perl ist und kein MOD installiert.
Apache bekommt niemals eine Aufforderung, irgendein Script auszuführen. Das kann er nicht. Er kann aber aufgrund einer Anfrage vergleichen, ob in seiner Konfiguration vorgesehen ist, welcher "Partner" (beispielsweise Perl) ein Script ausführen dürfte, und dem dann das Script zur gefälligen Abarbeitung übergeben. Was du jetzt mit MOD meinst, ist mir unklar. Um den Perl-Interpreter um die Ausführung irgendeines Scripts zu bitten, muß der Apache überhaupt nix von irgendeinem mod_* wissen.

Quatsch

Der client macht eine Anfrage an den Server der in unserem Falle Apache ist.

ist es ein normaler Apache da hast du dann recht sucht er den Partner, aber ich habe nichts anders gemeint, wenn du "richtig" lesen würdest.

Und wenn aber Apache-perl aufgerufen wird) Was geschieht dann mit einem perlscript-Aufruf?
Damit du nicht gleich wieder mit einer Spitzfindigkeit rüberkommst ;-)
Dir ist klar was folgendes bedeutet?

<IfModule mod_perl.c>

Ach ist das etwa ein als MODul integrierter Perlinterpreter?
Frage ist ein Apache-Modul ein Teil vom Apache oder nicht?

Also ruft er den Perl-interpreter auf. Von dem bekommt er zuerst die Redirektion oder einen anderen Output zurück über den STDOUT.

STDOUT? Wie sollte Apache damit umgehen?

Wie geht ein Programm wohl damit um, wenn sein Child-Prozess (und Perl ist ein Child vom Apache) auf stdout ausgibt?
in Perl muß indi dazu Backticks nehmen oder qx// da Perl in C geschrieben ist, muß das auch in C möglich sein. Apache ist doch in C geschrieben, wo ist also das Problem den Standard Output abzufangen?
Es fängt es auf und reagiert darauf. Ist natürlich abhängig, wie der Perlinterpreter gestartet wird, ob das passiert oder wie. Der Apache wird doch nicht beendet und überläßt alles weitere dem Perlinterpreter(wie es in perl EXEC machen würde) folglich wird auch der Rückgabewert des Interpreters bzw sein stdout weiterverarbeitet, wie sollte sonst aus dem Script beispielsweise die Daten einer HTML-Seite zum Server gelangen? Der Perl-Prozess startet doch nicht einen Apache-Prozess was er müßte, wenn er mit Exec aufgerufen wäre.
Wenn ich HTML ausgebe mit einem Perlscript, dann gebe ich zuerst den Header per print und dann die html-daten per print aus und print gibt nun mal auf stdout aus (wenn man das nicht verbiegt). Jedenfalls steht das so im Camelbook. Dann wird Perl einfach beendet, nix Apache aufrufen. Wer, wenn nicht der Apache, fängt bitte schön die Daten von stdout auf, um sie dem Client zugeben?

So und den Rest werde ich jetzt nicht nocheinmal kommentieren, du willst mich an dieser Stelle nicht verstehen, weil du wie vernagelt Daten und Authentifizierungsdaten nicht unterscheiden willst. Deshalb reden wir aneinander vorbei. Wer lesen kann ist klar im Vorteil ;-)
Nur noch eins, mir ist klar was /dev/null bedeutet. Dir ist aber nicht klar, das es längst nicht mehr um die ersten beiden Zeilen der .htaccess ging, sondern darum, zuerkennen, was erreicht werden sollte mit dem:  <Limit GET>

Hast du schon mal probiert welche Wirkung eine .htaccess-Datei im cgi-bin/ - pfad hat der keine der nachfolgenden Schlüsselworte enthält?

AuthUserFile AuthGroupFile AuthType

Ich meine, das das dann irgendwie sinnlos ist.

Joe

[Christoph Schnauß]

hallo Joe,

Dir ist klar was folgendes bedeutet?
<IfModule mod_perl.c>

Selbstverständlich.

Frage ist ein Apache-Modul ein Teil vom Apache oder nicht?

Selbstverständlich ist es das - nur solltest du dir anschauen, wozu man welche Modul braucht. mod_perl braucht man nicht unbedingt, wenn man Perl-Scripts ausführen lassen möchte. Du kennst die zugehörige Doku, die die Liste der Apache-Module darstellt? Findest du dort irgendwo mod_perl? Wenn nein: warum fehlt es dann? Was liest du auf http://perl.apache.org/start/index.html? Was passiert, wenn du mod_perl deinstallierst und trotzdem ein Perl-Script als CGI-Anweisung aufzurufen versuchst?

Wie geht ein Programm wohl damit um, wenn sein Child-Prozess (und Perl ist ein Child vom Apache) auf stdout ausgibt?

Perl ist nicht zwingend ein "Child" des Apache. Und falls es was auf STDOUT ausgibt, steht das eben da. Fertig.

Wenn ich HTML ausgebe mit einem Perlscript, dann gebe ich zuerst den Header per print und dann die html-daten per print aus und print gibt nun mal auf stdout aus

Womit möglicherweise dein Browser etwas anfangen kann, nicht aber der Apache.

Hast du schon mal probiert welche Wirkung eine .htaccess-Datei im cgi-bin/ - pfad hat der keine der nachfolgenden Schlüsselworte enthält?
AuthUserFile AuthGroupFile AuthType
Ich meine, das das dann irgendwie sinnlos ist.

Glaube mir, ich dürfte da mehr probiert haben als mancher andere. Und es ist bemerkenswert, daß dir hier die Bezeichnung "sinnlos" einfällt. Schließlich ist es auch nicht der Pfad, der irgendeines der von dir so genannten Schlüsselwörter aufweisen muß.

Grüße aus Berlin

Christoph S.

[Joe]

hallo Christoph,

Selbstverständlich.

Cool!

... mod_perl braucht man nicht unbedingt, wenn man Perl-Scripts ausführen lassen möchte.

Klaro, Ich habe noch nicht damit gearbeitet, aber immer wieder hingeschielt.:-)

Du kennst die zugehörige Doku, die die Liste der Apache-Module darstellt?

Jain, also nicht wirklich, denn als ich mich um die Installierung kümmern mußte, da gab es 2.2 noch lange nicht. Damals begann es erst mit mod_perl und wenn ich Glück habe finde ich auf einem alten Rechner auch noch eine Doku, wo mod_perl unter den Modulen aufgeführt wurde.

Findest du dort irgendwo mod_perl? Wenn nein: warum fehlt es dann?

Keine Ahnung sag du es mir!

Was liest du auf http://perl.apache.org/start/index.html? Was passiert, wenn du mod_perl deinstallierst und trotzdem ein Perl-Script als CGI-Anweisung aufzurufen versuchst?

Na, der externe Interpreter wird "zur Hilfe gerufen"(falls er in der Konfig...) . :-)

Wie geht ein Programm wohl damit um, wenn sein Child-Prozess (und Perl ist ein Child vom Apache) auf stdout ausgibt?

Perl ist nicht zwingend ein "Child" des Apache. Und falls es was auf STDOUT ausgibt, steht das eben da. Fertig.

Nix da! So einfach geht das nicht.
Aus der Doku 2.0 Apache:

#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}

Theoretisch nach deiner Auffassung müßte auf der Konsole des Rechners(stdout), wo der Apache läuft die Umgebungsvariablen des Perlscriptes ausgegeben werden.
Richtig?

Tatsache aber ist, das die Ausgabe letzten Endes im Browserfenster des Client-Rechners dargestellt wird. Das kann eigentlich nur passieren, wenn das Programm, das den Interpreter aufruft den Standard output "abfängt" und an den Client-Rechner überträgt wie auch immer.

Aus einem posting früher:

Er kann aber aufgrund einer Anfrage vergleichen, ob in seiner Konfiguration vorgesehen ist, welcher "Partner" (beispielsweise Perl) ein Script ausführen dürfte, und dem dann das Script zur gefälligen Abarbeitung übergeben.

Und dieses übergeben hat nichts mit STDIN oder Query_string im Environment zu tun?
Apache unterscheidet sehr wohl was es mit den Daten macht, die möglicherweise eine Clientanforderung begleiten. siehe ebenfalls
 http://httpd.apache.org/docs/2.0/de/howto/cgi.html#troubleshoot und dort an der Stelle STDIN/STDOUT
Leider finde ich da nicht den Rückweg, sondern nur den Hinweg zum Script beschrieben,

Wenn ich HTML ausgebe mit einem Perlscript, dann gebe ich zuerst den Header per print und dann die html-daten per print aus und print gibt nun mal auf stdout aus
Womit möglicherweise dein Browser etwas anfangen kann, nicht aber der Apache.

Anscheinend besteht hier wieder so ein sprachliches Mißverständniss, Denn du überließt anscheinend glatt den Header, gut ich habe nicht HTTP-Header oder wie das Ding heißt geschrieben...
Doch schau mal auf der gleichen erwähnten Seite:

For example, if the URL http://www.example.com/cgi-bin/test.pl  is requested, Apache will attempt to execute the file /usr/local/apache2/cgi-bin/test.pl  and return the output.

Ich kann zwar nicht gut Englisch, aber steht da nicht "Apache....and return the Output"?
Also bitte wo du doch wie lese sovielprobiert hast, Wie anders kommt der Apache an die Daten des Outputs des Perscriptes ran in obigen Beispiel?
Mit anderen Worten welche Art der Interprozess-Kommunikation kann verwendet werden, wenn Perl kein Child von Apache ist und auch nicht integriert ist.
Warum sollte Apache je nach Modus eine Environment-Variable oder den STDIN verwenden und dann den STDOUT nicht? Irgendwie müssen die Daten doch zum Client zurückkommen die angefordert wurden.

Hast du schon mal probiert welche Wirkung eine .htaccess-Datei im cgi-bin/ - pfad hat der keine der nachfolgenden Schlüsselworte enthält?
AuthUserFile AuthGroupFile AuthType
Ich meine, das das dann irgendwie sinnlos ist.

Glaube mir, ich dürfte da mehr probiert haben als mancher andere. Und es ist bemerkenswert, daß dir hier die Bezeichnung "sinnlos" einfällt. Schließlich ist es auch nicht der Pfad, der irgendeines der von dir so genannten Schlüsselwörter aufweisen muß.

Eben, wie ich schrieb "welche Wirkung eine .htaccess-Datei..." und ok, das 'der' müßte ein 'die' sein, dann ist es einfacher, aber ich meinte ja auch nicht die .htaccess-Datei direkt, sondern den durch sie ermöglichten Passwortschutz, der durch sie symbolisiert werden sollte. :-)
Du raubst mir _deine_ Zeit!!!
Oder macht es dir Spass, dich wie eine Maschine zu benehmen? ;-)

Joe

[Christoph Schnauß]

hallo,

#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}
Theoretisch nach deiner Auffassung müßte auf der Konsole des Rechners(stdout), wo der Apache läuft die Umgebungsvariablen des Perlscriptes ausgegeben werden.
Richtig?

Falsch. %ENV listet die CGI-Umgebungsvariablen auf, gibt also Informationen über die CGI-Schnittstelle. Du kannst dieses kleine Script auch von der Kommandozeile aus aufrufen, es liefert dieselben Aussagen - völlig ohne Apache. Und es handelt sich _nicht_ um "Umgebungsvariablen des Perlscriptes". Allerdings gibt es Perl-Module (CGI.pm beispielsweise), die eigene Umgebungsdaten definieren, wobei das oftmals den CGI-Umgebungsvariablen recht ähnlich sieht.

Tatsache aber ist, das die Ausgabe letzten Endes im Browserfenster des Client-Rechners dargestellt wird. Das kann eigentlich nur passieren, wenn das Programm, das den Interpreter aufruft den Standard output "abfängt" und an den Client-Rechner überträgt wie auch immer.

Nicht ganz richtig. Das kann es, weil der Interpreter natürlich so brav ist, ihm zusätzlich diese angeforderten Daten nochmals zur Verfügung zu stellen, so daß er sie an den anfragenden Client weiterreichen kann.

Und dieses übergeben hat nichts mit STDIN oder Query_string im Environment zu tun?

Wieso nun STDIN (und nicht mehr STDOUT)? Und was würde geschehen, wenn %QUERY_STRING leer ist?

Apache unterscheidet sehr wohl was es mit den Daten macht, die möglicherweise eine Clientanforderung begleiten.

Selbstverständlich. Das ist Teil der Client/Server-Kommunikation. Vieles dazu kannst du übrigens in SELFHTML nachlesen.

Leider finde ich da nicht den Rückweg, sondern nur den Hinweg zum Script beschrieben,

Schön, daß dir diese Erkenntnis kommt.

For example, if the URL http://www.example.com/cgi-bin/test.pl  is requested, Apache will attempt to execute the file /usr/local/apache2/cgi-bin/test.pl  and return the output.
Ich kann zwar nicht gut Englisch, aber steht da nicht "Apache....and return the Output"?

Wichtiger ist "will attempt to execute". Apache wird feststellen, daß er das gar nicht kann, aber glücklicherweise gibt es ja noch die shebang, in der steht, wer es kann. Also wird Apache seine Bemühungen aufgeben und das Script dankbar an den Perl-Interpreter übergeben.

Oder macht es dir Spass, dich wie eine Maschine zu benehmen? ;-)

"Wir sind Borg. Widerstand ist zwecklos".

Grüße aus Berlin

Christoph S.

[Joe]

hallo,

#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}
Theoretisch nach deiner Auffassung müßte auf der Konsole des Rechners(stdout), wo der Apache läuft die Umgebungsvariablen des Perlscriptes ausgegeben werden.
Richtig?

Falsch. %ENV listet die CGI-Umgebungsvariablen auf, gibt also Informationen über die CGI-Schnittstelle. Du kannst dieses kleine Script auch von der Kommandozeile aus aufrufen, es liefert dieselben Aussagen - völlig ohne Apache. Und es handelt sich _nicht_ um "Umgebungsvariablen des Perlscriptes". Allerdings gibt es Perl-Module (CGI.pm beispielsweise), die eigene Umgebungsdaten definieren, wobei das oftmals den CGI-Umgebungsvariablen recht ähnlich sieht.

Wieso dann falsch?
Ich bezog mich auf den Output des Perlscriptes wie du nachlesen kannst. Diese werden im Script mit print auf STDOUT ausgegeben. Das dieses Script auch von der Komandozeile aufrufbar ist spielt keine Rolle. Und Environment sollte jedes Progi haben, aber nicht immer mit gleichem Inhalt, Jenachdem wie es aufgerufen wird und was der Parentprozess liefert.
In unserem Fall werden die CGI-typischen Environmentvariablen von Apache ins Environment geschrieben und je nach Methode (GET oder POST der Anforderung) wird eben auch STDIN benutzt, Steht übrigens in der Apache-Doku kannste nach lesen.

In sofern ist deine Aussage falsch, das dieser Script die gleiche Ausgabe erzeugen würde.
Eine CGI-Umgebung zeichnet sich dadurch aus, das eine Reihe Server-Informationen dort abgelegt sind, HTTP-Refferer etc. Und die Shell gibt wieder ein anderes Environment mit
Deshalb werden die Ausgaben sehr unterschiedlich sein.

Beweis:

1. Über cgi werden diese ausgegeben:
SCRIPT_NAME SERVER_NAME SERVER_ADMIN HTTP_ACCEPT_ENCODING HTTP_CONNECTION REQUEST_METHOD HTTP_ACCEPT SCRIPT_FILENAME SERVER_SOFTWARE HTTP_ACCEPT_CHARSET QUERY_STRING REMOTE_PORT HTTP_USER_AGENT SERVER_SIGNATURE SERVER_PORT HTTP_ACCEPT_LANGUAGE REMOTE_ADDR HTTP_KEEP_ALIVE
SERVER_PROTOCOL PATH REQUEST_URI GATEWAY_INTERFACE SERVER_ADDR DOCUMENT_ROOT HTTP_HOST

2. Über die Shell werden diese ausgegeben:
HOME LANGUAGE KONSOLE_DCOP_SESSION SSH_AGENT_PID DISPLAY GTK_RC_FILES XDM_MANAGED SSH_AUTH_SOCK PWD GTK2_RC_FILES LANG USER XCURSOR_THEME LOGNAME GS_LIB SHLVL OLDPWD _ DESKTOP_SESSION PATH KONSOLE_DCOP WINDOWID COLORTERM SHELL XPSERVERLIST KDE_FULL_SESSION TERM DM_CONTROL SESSION_MANAGER PAGER KDE_MULTIHEAD

Siehst du irgendwelche Gleichheit, wenn ja definiere gleich!

Deine Aussage 'Und es handelt sich _nicht_ um "Umgebungsvariablen des Perlscriptes".' ist definitiv falsch!

Zitat Camelbook S.683:
%ENV
Dieser Hash enthält Ihre aktuellen Umgebungsvariablen. Wird ein Wert in %ENV gesetzt, ändert sich die Umgebung für Ihren Prozess und die nachfolgenden gestarteten Child-Prozesse.(Die Umgebung des Parent-Prozess kann bei keinem UNIX-System geändert werden.)

Für mich ist perl und perlscript in der Laufzeit übrigens identisch, Falls du wiedermal spitzfindig meine Formulierung auseinandernehmen willst, und das aus gutem Grund, denn perl ist kein reiner Interpreter. Als Mensch bin ich in der Lage Aussagen zu verdichten!
Und deine Art und Weise ganze Aussagen als Falsch zu bezeichen, nur weil statt das Script der Script geschrieben wurde stinkt zum Himmel. (Tschuldigung)

Tatsache aber ist, das die Ausgabe letzten Endes im Browserfenster des Client-Rechners dargestellt wird. Das kann eigentlich nur passieren, wenn das Programm, das den Interpreter aufruft den Standard output "abfängt" und an den Client-Rechner überträgt wie auch immer.
Nicht ganz richtig. Das kann es, weil der Interpreter natürlich so brav ist, ihm zusätzlich diese angeforderten Daten nochmals zur Verfügung zu stellen, so daß er sie an den anfragenden Client weiterreichen kann.

Und wie soll das geschehen? Vor allem, wenn in der Apache-Doku ebenfalls STDOUT erwähnt wird?
Wozu sollte perl eine Information zweimal liefern?
Gibt das Scriptum ohne einen HTTP-Header etwas mit print auf STDOUT aus, landet es im error-log des Apache. Am Header erkennt Apache, was er also machen soll.
Es wäre unsinniger Overhead müßte der perl-interpreter ermitteln, wie das Script aufgerufen wurde und nach deiner Aussage entsprechend zweimal eine Information liefern würde, einmal an STDOUT und einmal an Apache.
Viel einfacher wäre es, wenn Apache den STDOUT vor dem Aufruf des Interpreters verbiegt. und
nach dem beenden dann diese Daten auswertet. Perlweis das aber nicht, sondern gibt stur auf STDOUT aus. Eine Verdopplung der Daten, wie du das siehst, ist Unfug, es sei denn, es gäbe gute Gründe dafür. Dann leg mal los! (Interprozess-Kommunikation? wo?)

Und dieses übergeben hat nichts mit STDIN oder Query_string im Environment zu tun?
Wieso nun STDIN (und nicht mehr STDOUT)? Und was würde geschehen, wenn %QUERY_STRING leer ist?

(Das kannst du deiner eigenen Aussage entnehmen:
"...und dem dann das Script zur gefälligen Abarbeitung übergeben."
Ich bezog mich auf das letzte Wort in deinem Satz.)

Definiere leere Environmentvariable! ;-)

Entweder ist eine Env-Var da oder nicht da, wenn sie da ist, hat sie Inhalt.

Übrigens gipt es keinen solchen %QUERY_STRING Hash in perl. :-)
Aber du meinst bestimmt $ENV{'QUERY_STRING'} oder?

For example, if the URL http://www.example.com/cgi-bin/test.pl  is requested, Apache will attempt to execute the file /usr/local/apache2/cgi-bin/test.pl  and return the output.
Ich kann zwar nicht gut Englisch, aber steht da nicht "Apache....and return the Output"?
Wichtiger ist "will attempt to execute". Apache wird feststellen, daß er das gar nicht kann, aber glücklicherweise gibt es ja noch die shebang, in der steht, wer es kann. Also wird Apache seine Bemühungen aufgeben und das Script dankbar an den Perl-Interpreter übergeben.

Also in meiner Aussage ist erstmal wichtig, das damit von Seiten der Doku bestätigt wird, das Apache den Output "returniert" an den Client. Das hast du ja zuerst nicht eingeräumt.
Es ist auch nicht so wichtig, das Apache das, was er nicht selbst kann, an andere weiter gibt
Davon ging ich bis her immer aus, insofern ist das trivial.

"Wir sind Borg. Widerstand ist zwecklos".

:-))))
He, du regst mich uff, aber macht nix!
Bin Mensch, und was ich nicht integrieren kann wird gefressen ;-)

Joe

[Der Martin]

Hallo Joe,

#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}

Theoretisch nach deiner Auffassung müßte auf der Konsole des Rechners(stdout), wo der Apache läuft die Umgebungsvariablen des Perlscriptes ausgegeben werden.
Richtig?

falsch. Sie werden dorthin ausgegeben, worauf STDOUT verweist. Und die Standard-Handles STDIN, STDOUT, STDERR etc. "erbt" ein Prozess nunmal von dem, der ihn aufruft.
Heißt im Klartext:
Wird der Perl-Interpreter von der Shell aus aufgerufen, erbt er deren STDxxx-Handles; eine Ausgabe auf STDOUT wird daher _in der Regel_ auf der Konsole erscheinen.
Wird der Perl-Interpreter dagegen vom Apachen aufgerufen, erbt er dessen STDOUT. Und das hat der Apache schon so zurechtgebogen, dass Ausgaben an dieses Handle direkt zum anfragenden Client gehen. Gibt ein Perl-Script in *dieser* Konstellation etwas auf STDOUT aus, geht das also am Apachen vorbei direkt zum Client.

Tatsache aber ist, das die Ausgabe letzten Endes im Browserfenster des Client-Rechners dargestellt wird.

Eben.

Das kann eigentlich nur passieren, wenn das Programm, das den Interpreter aufruft den Standard output "abfängt" und an den Client-Rechner überträgt wie auch immer.

Nein. Wenn Kollege A mich anruft und sagt, er bräuchte die Unterlagen über Projekt xyz, die ich aber selbst nicht habe, dann kann ich mir diese Unterlagen vom Kollegen B holen und eigenhändig an den Kollegen A durchreichen. Das ist deine Denkweise. Ich kann aber auch B Bescheid geben und ihn bitten, die Sachen gleich dem Kollegen A zu geben. Dann hab ich nichts mehr damit zu tun und sehe auch nicht, was die beiden *wirklich* untereinander austauschen.

Anscheinend besteht hier wieder so ein sprachliches Mißverständniss, Denn du überließt anscheinend glatt den Header, gut ich habe nicht HTTP-Header oder wie das Ding heißt geschrieben...

Aber hoffentlich *gemeint*. Ich wüsste nicht, was du sonst für einen Header meinen könntest. Und den braucht ja auch nicht der Apache, sondern der anfragende Client.

For example, if the URL http://www.example.com/cgi-bin/test.pl  is requested, Apache will attempt to execute the file /usr/local/apache2/cgi-bin/test.pl  and return the output.
Ich kann zwar nicht gut Englisch, aber steht da nicht "Apache....and return the Output"?

Ja, aber das ist sehr salopp formuliert und technisch nicht ganz korrekt.

Also bitte wo du doch wie lese sovielprobiert hast, Wie anders kommt der Apache an die Daten des Outputs des Perscriptes ran in obigen Beispiel?

Gar nicht. Das interessiert ihn nicht.

Mit anderen Worten welche Art der Interprozess-Kommunikation kann verwendet werden, wenn Perl kein Child von Apache ist und auch nicht integriert ist.

Der Perl-Interpreter *ist* ein Child-Prozess des Apachen, wenn er in dessen Kontext als CGI aufgerufen wird. Die Kommunikation der beiden beschränkt sich aber darauf, dass der Indianer aufpasst, wann Perl beendet ist, und dann die verbleibenden Pfützen des Requests aufwischt.

Du raubst mir _deine_ Zeit!!!

Christoph versucht verzweifelt, dir die Zusammenarbeit von Apache und Perl klarzumachen, aber du scheinst das nicht zu verstehen. Es wirkt auf mich so, als wärst du in deiner Vorstellung so festgefahren, dass du andere Darstellungen nicht einmal als Möglichkeit überdenkst.

So long & good night,
 Martin

[Christian Seiler]

Hallo Martin,

Wird der Perl-Interpreter dagegen vom Apachen aufgerufen, erbt er dessen STDOUT. Und das hat der Apache schon so zurechtgebogen, dass Ausgaben an dieses Handle direkt zum anfragenden Client gehen. Gibt ein Perl-Script in *dieser* Konstellation etwas auf STDOUT aus, geht das also am Apachen vorbei direkt zum Client.

Das ist stark simplifiziert und stimmt so nur für NPH-Scripte. Der Apache biegt das STDOUT von CGI-Scripten (egal ob Perl oder sonstwas) wie Du gesagt hast um, allerdings nicht auf den Client-Socket, sondern auf irgendwas, mit dem zwei Prozesse kommunizieren können. Der Apache liest dann "am anderen Ende" die Ausgabe ein, wartet auf den Trenner zwischen Header / Body, wurschtelt dann noch etwas an den Headern rum (eine Antwort enthält viel mehr Header, als das CGI-Script setzt) und gibt dann alle Header in einem Rutsch aus. Die Body wird idR. direkt "durchgeleitet" - allerdings kann es noch sein, dass noch weitere Filter drauf losgelassen werden (mod_gzip/mod_deflate z.B., die den Datenstrom on-the-fly komprimieren, um Übertragungszeit zu sparen).

Viele Grüße,
Christian

[Joe]

Hallo Martin,

Theoretisch nach deiner Auffassung müßte auf der Konsole des Rechners(stdout), wo der Apache läuft die Umgebungsvariablen des Perlscriptes ausgegeben werden.
Richtig?
falsch.

Natürlich falsch,aber richtig, wenn ich dem Wortlaut von Christoph folge,

Sie werden dorthin ausgegeben, worauf STDOUT verweist.

Mein reden!

Und die Standard-Handles STDIN, STDOUT, STDERR etc. "erbt" ein Prozess nunmal von dem, der ihn aufruft.

Wie ich es beschrieb oder zumindest gemeint habe!

Heißt im Klartext:
Wird der Perl-Interpreter von der Shell aus aufgerufen, erbt er deren STDxxx-Handles; eine Ausgabe auf STDOUT wird daher _in der Regel_ auf der Konsole erscheinen.
Wird der Perl-Interpreter dagegen vom Apachen aufgerufen, erbt er dessen STDOUT. Und das hat der Apache schon so zurechtgebogen, dass Ausgaben an dieses Handle direkt zum anfragenden Client gehen. Gibt ein Perl-Script in *dieser* Konstellation etwas auf STDOUT aus, geht das also am Apachen vorbei direkt zum Client.

Das demonstrierte/bewies ich  mit den Ausgaben des Test-Scriptes.

Das kann eigentlich nur passieren, wenn das Programm, das den Interpreter aufruft den Standard output "abfängt" und an den Client-Rechner überträgt wie auch immer.
Nein. ...Das ist deine Denkweise. Ich kann aber auch B Bescheid geben und ihn bitten, die Sachen gleich dem Kollegen A zu geben. Dann hab ich nichts mehr damit zu tun und sehe auch nicht, was die beiden *wirklich* untereinander austauschen.

Ok, darum habe ich nach einer anderen Prozesskommunikation gefragt die das leisten soll!
Ich stecke ja nicht in den Sourcen und kenne daher nicht wie dasder Apache macht, sondern betrachte von Außen und von den Kenntnissen welche Systemaufrufe es auf allen UNIX-Systemen gibt.

Aber hoffentlich *gemeint*. Ich wüsste nicht, was du sonst für einen Header meinen könntest. Und den braucht ja auch nicht der Apache, sondern der anfragende Client.

Er hätte mich mißverstehen können, weil html ja auch ein HEAD-Element kennt. :-)

For example, if the URL http://www.example.com/cgi-bin/test.pl  is requested, Apache will attempt to execute the file /usr/local/apache2/cgi-bin/test.pl  and return the output.
Ich kann zwar nicht gut Englisch, aber steht da nicht "Apache....and return the Output"?
Ja, aber das ist sehr salopp formuliert und technisch nicht ganz korrekt.

Dafür kann ich nichts.:-)

Also bitte wo du doch wie lese sovielprobiert hast, Wie anders kommt der Apache an die Daten des Outputs des Perscriptes ran in obigen Beispiel?
Gar nicht. Das interessiert ihn nicht.

invisible steht da noch (wenn er laut der Doku die Sache Returned (zurück gibt)) :-)
Und dann kam die oben bereits erwähnte Frage nach dem, was ich bisher mit "wie auch immer" bezeichnete. Eigentlich hätte ich noch präziser Fragen können, aber Christoph hätte längst einräumen können, das ein Child-Prozess _immer_ zu seinem Parent zurückkehrt (Wait-Befehl)
Aber er wollte es ja nicht anders, denn er behauptete ja das das Environment des Test.pl gleich wäre egal ob über Shell oder Apache aufgerufen.

Mit anderen Worten welche Art der Interprozess-Kommunikation kann verwendet werden, wenn Perl kein Child von Apache ist und auch nicht integriert ist.
Der Perl-Interpreter *ist* ein Child-Prozess des Apachen, wenn er in dessen Kontext als CGI aufgerufen wird. Die Kommunikation der beiden beschränkt sich aber darauf, dass der Indianer aufpasst, wann Perl beendet ist, und dann die verbleibenden Pfützen des Requests aufwischt.

Moment. Wie wird der Interpreter aufgerufen! (oder wird zuerst ein anderes Programm aufgerufen das den rest managed?)
Ich hatte bisher drei Möglichkeiten im Kopf:
1. Das was bei perl exec heißt - da würde sich der Apache beenden und Perl übernimmt, ohne das der Apache wieder ans Ruder kommt (scheidet aus wenn ich die Doku ernst nehme)
2. Das was man bei perl system nennt (unterscheidet sich von exec weil zuerstein fork ausgeführt wird)  aber da bekommt man nur _einen_ Rückgabewert.
3. Das was man bei perl  Backticks oder qx// nennt. Dabei bekommt man endlich auch den STDOUT  zurück.

Also,ich kann ja nur spekulieren, wenn Apache will, das nach dem Aufruf Apache weitermachen kann, und wenn es Pfützen aufräumen ist, dann wird er nicht "Exec" nehmen und wenn der STDOUT irgend wie von Interesse ist, wird das Standardhandle vor dem perl aufruf verbogen, um die Daten zu erhalten. Selbst wenn Apache selbst nichts mit den Daten anfangen will und sie gleich weiterreicht.
Um aber auch deiner Argumentation gerecht zu werden überlege ich folgendes:
Was, wenn Apache zuerst sich selbst als Child aufruft, dann könnte der Zweite Apache über exec gehen. Doch dann würde Perl immer noch child vom ersten Apache sein. Egal wie ich es wende der Apache startet den Perl-Prozess als Child und bekommt zuerst die Daten zurück.
Es ist auch gleich gültig, ob dann für den Tranfer oder Filterung der Ausgabe wiederum Child-Prozesse gestartet werden würden, Wo soll denn da der Denkfehler sein?

Christoph versucht verzweifelt, dir die Zusammenarbeit von Apache und Perl klarzumachen, aber du scheinst das nicht zu verstehen.

Zwischen uns ist ein Medium. Wir haben nur unsere Argumente, Ob ihr mir nun Quatsch erzählt oder ich euch kann keiner genau wissen. Nur Argumente können zählen. (und Beweise)

Es wirkt auf mich so, als wärst du in deiner Vorstellung so festgefahren, dass du andere Darstellungen nicht einmal als Möglichkeit überdenkst.

0 und 1 ist nunmal 0 und  1 :-)
Das kannst du mir nicht vorwerfen. (s.o.) Du hast mit einem Zitat begonnen, wo ich mich genau auf die Worte Christoffs eingelassen habe.
Und auch in diesem Beitrag kann ich doch nur über "mein" Modell der Wirklichkeit schreiben, sonst würde ich doch nur Nachplappern. Ich bin doch nicht bekloppt, Habe in der 68030 Schiene Assembling gecodet und einige Erfahrung mit Betriebssystemen. Zwar sind Hardcoderzeiten bei mir längst vorbei, aber ein x für ein u vormachen lasse ich mir noch lange nicht. Ich will es wissen, nicht glauben. Und solange sich eine neue Information nicht einordnet in das bisherige, ist was faul dran. Also muß ich fragen und dabei mein Modell zeigen damit der andere darin die Fehler entdecken kann, wenn er recht hat und einsehen kann, wenn er unrecht hat.
Ist doch ganz einfach!
Das nervt zwar, aber wer nicht fragt bleibt dumm.  :-)
Jeder spricht eine eigene Sprache und lebt in einer eigenen Welt. Das gemeinsame ist harte Arbeit.

Joe

[wahsaga]

hi,

Wenn eine Scriptausführung durchgeführt wird, Dann ist doch der Apache in diesem Moment an der Überwachung der Ordner garnicht mehr beteiligt. Praktisch könnte der Script auch auf Bereiche außerhalb der documentroot zugreifen, soweit es der Rechneradmin zuläßt und auch innerhalb der documentroot ist das nur von den Dateirechten abhängig und nicht vom Apache. Wenn das Script eine Redirektion durchführen würde, käme doch erst der Apache wieder ins Spiel.

Kurz und Knapp: HTTP betreffende Direktiven kommen nur dann zur Anwendung, wenn der Zugriff über HTTP erfolgt.
Ein Zugriff von einem Script auf Inhaltes des Dateisystem des Servers haben nichts mit HTTP zu tun, also sind dem Script solche Direktiven egal.

Wenn ich richtig liege, sollen die untergeordneten Verzeichnisse vor Zugriffen von Außen geschützt werden

Dazu reichte, wie bereits gesagt, DENY FROM ALLOW vollkommen aus.
Irgendwelche HTTP-Auth-Geschichten sind dafür absolut nicht notwendig.

Im Gegenteil, HTTP Auth stellt ja kein komplettes Verbot dar, sondern ermöglicht Zugriff unter bestimmten Bedingungen.
Da hier aber was die Zugangsdaten angeht auf /dev/null verwiesen wird, ist auch das wieder blödsinnig, es kann keinen per HTTP Auth zugelassenen Zugriff auf die Ressourcen geben.

gruß,
wahsaga