Bitte um kurzes Review

[Alexander (HH)]

Moin Moin!

use constant XHTMLTEMPLATE => '../RealWorld/template.xsl';
Wer oder was garantiert Dir, dass das Script im "richtigen" Verzeichnis aufgerufen wird? Absolute Pfade würden meiner Paranoia weniger weh tun.

Es gibt nur ein CGI-Verzeichnis auf dem Webserver. Ich bevorzuge eigentlich relative Pfade weil ich sie für flexibler halte (sofern Relationen stimmen): Ich kann das komplette '../'-Verzeichnis frei bewegen. Warum macht dir das Angst? Ich habe jetzt trotzdem absoltue Pfade verwendet:

Wer garantiert Dir, das zu jeder Zeit das CGI-Verzeichnis das aktuelle Verzeichnis ist? Irgendein nachgeladenes Modul oder eine externe Library könnte chdir() aufrufen -- vielleicht sogar in der Absicht, dass wieder rückgängig zu machen, was aber aus merkwürdigen Gründen (Permissions, ...) nicht klappt.

use constant PLAINCACHE => 'feed.tmp';
Das aktuelle Verzeichnis ist für den WWW-User (sprich: das GESAMTE Internet) BESCHREIBBAR? SOFORT ABSTELLEN!
Sowas in der Art habe ich erwartet ;-) Aber keine Angst, das Skript hängt nicht am Netz.

Je nach Quelle kommen 75% bis 90% der Angriffe von innen.

Es ist nur diese eine Datei durch www-data veränderbar. Das Skript und die Temp-Datei liegen im CGI-Verzeichnis, wobei der Apache "nur" .cgi-Dateien ausführen darf. feed.tmp ist aber nicht executable und wird vor jeder Verwendung komplett neu erzeugt.

Und wenn zwei Requests sich überschneiden (den Scheduler des Betriebssystems kannst Du nicht aussperren)? Dann schrottet der eine Request die Datei, die der andere Request gerade mühsam aufgebaut hat.

»  Ansonsten benutze ein Modul, das sicheren Umgang mit Temp-Files garantiert.
Zum Beispiel File::Temp? Das muss ich morgen mal ausprobieren.

Ja, aber bitte nicht die Legacy-Funktionen.

Leider brauche ich das Temp-File. Ich schreibe nun über die --output-Option von xsltproc in die Datei. Ob dies vor simultanen Zugriffen schützt wage muss ich noch abklären.

Vermutlich nicht. O_CREATE und O_EXCL müßten beim Aufruf von open() in xsltproc gesetzt sein und es darf kein NFS im Spiel sein, damit das einigermaßen klappt. Die open()-Manpage rät dazu, separate Lock-Files zu benutzen.

Eine geschützte Datei würde sich gut als Cache eignen, aber eventuell werde ich für jeden Aufruf eine eigene Temp-Datei erzeugen müssen.

Richtig. Und der Name sollte nicht vorhersagbar sein. File::Temp sollte helfen.

perldoc perlipc: Safe Pipe opens sollte Dir helfen. Im Child machst Du jeweils ein exec @xlst_with_arguments ohne IO Redirection, im Parent ein print while <KID_TO_READ>.

Phu, das war schwere Kost! Doch leider scheinen mir diese Pipes für meinen Zweck nicht ganz richtig geeignet. (Ich brauche Dateien, nicht deren Inhalt).

Letztlich sendest Du den Dateiinhalt. Wenn Du xsltproc in einem Subprozess dazu bringst, nach STDOUT zu schrieben, kannst Du die Ausgabe im Parent per KID_TO_READ einsammeln -- ganz ohne Temp-Datei.

Ich habe schon ein paar mal versucht das Modul XML:LibXSLT zu installieren, doch leider haut das bei mir nicht hin. Konnte nicht heraus finden wo das Problem liegt.

Betriebssystem? Version? Distribution? Version? Perl-Version? Fehlermeldung von cpan -i XML::LibXSLT?

Doch um von den system-Calls weg zu kommen gibt es wohl nichts besseres.

Denkst du das haut jetzt hin? Gruss & Dank

Du hast immer noch Race Conditions rund um das Temp-File. Und wenn ich die Paranoia richtig hochjage, hast Du keine Garantie, dass xsltproc nicht bei passendem Input Amok läuft und Deine Oma umbringt.

Alexander