"open() und sysopen()" /? (Perl/CGI)

[thread]9968[/thread]

"open() und sysopen()" /?

BlackExe

2007-08-05 00:48

User since
2007-03-25
49 Artikel
BenutzerIn
[default_avatar]

Hallo Leute ... :_))

Wollte Euch mal wieder um Rat bitten!
Und zwar habe ich verständnisprobleme, mit einigen Fragen zur Sicherheit?

Habe gestern gelesen, das zum öffnen einer Datei, die "sysopen-Methode" sicherer sei als die "open-Methode"? Ich habe das irgendwie nicht richtig verstanden gehabt weil auch nicht viel Text dabei stand ... ?

Habe aber mal ein Beispiel gemacht:
Datei zum Lesen öffnen=>(Lesezugriff)

Code (perl): (dl )

#!C:\perl\bin\perl.exe
##!/usr/bin/perl -w -T

use strict;
use warnings;
use CGI::Carp qw(fatalsToBrowser);
use Fcntl qw/:DEFAULT :flock/;
$CGI::POST_MAX=1024 * 100;
$CGI::DISABLE_UPLOADS = 1;

my $file = "data12.dat";
my @data;

sysopen(file, $file, O_RDONLY) or die $!;
flock(file, LOCK_SH) || die "flock failed $file $!";
@data = <file>;
close(file) or warn "close failed $file $!";

print "Content-type: text/html\n\n";
print "@data\n";

Jetzt wollte ich Euch mal Fragen ob mein Beispiel, mit der sysopen-Methode so richtig ist und ob man das verwenden kann?

Auchso eine Frage habe ich denn noch?
Und zwar bekomme ich immer eine Fehlermeldung wenn ich eine Mail unter "Taint"
verschicken möchte, ohne "-T" geht es?

Code (perl): (dl )

open(MAIL, "|/usr/lib/sendmail -t");

Könnte mir da jemand weiterhelfen, wie das mit der Mail unter "Taint" richtig ist?

Gruß /BlackExe ... :_))

Glaube denen, die die Wahrheit suchen, und zweifle an denen, die sie gefunden haben.

RalphFFM

2007-08-05 00:53

User since
2006-11-16
258 Artikel
BenutzerIn

Wenn ich mich recht entsinne ist sysopen insofern sicherer, weil öffnen und locking in einem Schritt getan werden können. Außerdem wird bei sysopen im Gegensatz zu open auch nicht gebuffert, was aber mit der Sicherheit erstmal wenig zu tun hat.

BlackExe

2007-08-05 01:37

User since
2007-03-25
49 Artikel
BenutzerIn
[default_avatar]

Hallo RalphFFM ... :_))

Danke für Deine Antwort!
Ich kann mit dem Begriff: "gebuffert" noch nix anfangen,
könntest Du mir da noch mal ein Link zu geben, damit ich mir das
anlesen kann?

Gruß /BlackExe ... :_))

Glaube denen, die die Wahrheit suchen, und zweifle an denen, die sie gefunden haben.

RalphFFM

2007-08-05 01:56

User since
2006-11-16
258 Artikel
BenutzerIn

http://www.thomas-fahle.de/pub/perl/Diverses/Open_...
(Von "unserem" Thomas!)

Erwähnen möchte ich noch, daß man open und sysopen nicht mischen sollte wenns dieselbe Datei betrifft, und letztere mehrmals in einem Skript öffnen/schließen möchte.

Noch eine Anmerkung zu Deiner Frage "ob man das [Skript] so verwenden kann".
Also ich nehme use warnings/strict/diagnostics/usw. nur zum Testen. Für den Produktivbetrieb nehme ich das wieder raus, um böswilligen Leuten nicht unbedingt auch noch skriptinterne Infos zukommen zu lassen. (Weiß aber nicht ob das der Mainstream auch so macht.)

Nun zu Deiner anderen Frage: Wie lautet denn die Fehlermeldung von Taint wenn Du die Mail versenden möchtest?
(PS: Zwei eher nicht zusammenhängende Fragen in 1 Thema zusammen ist finde ich ist nicht so der Hit.)

topeg

2007-08-05 02:01

User since
2006-07-10
2611 Artikel
BenutzerIn

user image

Zum Thema puffern:

Normalerweise werden Schreib/Lese-Aktionen auf Dateien, die Konsole, oder andere Datenstreams gepuffert. Das bedeutet, dass alle Aktionen Zwischengespeichert werden, um sie in einem günstigen Moment auszuführen (z.B. wenn Das OS nichts anderes zu tun hat, oder genügend Datenkapazität übers Netzwerk zur Verfügung steht.) In perl dient es zudem um die Ausgabe zu beschleunigen. So wird zum schreiben normalerweise auf ein "\n" gewartet, um dann eine ganze Zeile schreiben zu können.
Es gibt die vordefinierte Variable "$|", die sämtliche Puffer für alle geöffneten Filehandles (Ein/Ausgabestreams) abschaltet.

Sieh auch:

Code: (dl )

perldoc -q flush

BlackExe

2007-08-05 02:06

User since
2007-03-25
49 Artikel
BenutzerIn
[default_avatar]

Hallo RalphFFM ... :_))

Ich Danke nochmal für Deine Informationen und Hilfe,
werde mir das nochmal alles genauer ansehen.

Sorry, da haste Recht werde zum "Mail" Problem nochmal ein neues Thema erstellen.
Danke für den Hinweis.

EDIT: //
------------------
@topeg ... :_))

Danke, für die gute Erklärung!

Gruß /BlackExe ... :_))

Glaube denen, die die Wahrheit suchen, und zweifle an denen, die sie gefunden haben.

Gast Gast

2007-08-05 02:45

sysopen() buffert genauso wie open().

Ansonsten hängt es davon ab was du genau machen möchtest, und ob es sicherer ist.

Und öffnen + locking kann auch bei sysopen() nicht in einen Schritt gemacht werden. Leider verstehen da viele das Attibut O_EXCL falsch.

Und jetzt alles etwas genauer.
Zu der Sicherheit. Stell dir vor du möchtest eine Datei erstellen. Du möchtest aber keine bereits vorhandene Datei überschreiben. Du kommst also zu der Idee folgenden Code zu schreiben.

Code (perl): (dl )

if ( -e $file ) {
    die "Datei gibt es schon\n";
}
open my $fh, '>', $file  or  die $!;

Sieht im ersten Moment richtig aus. Wenn die Datei existiert brichst du ab. Ansonsten wird die Datei erstellt.

Auf den zweiten Blick sieht es etwas anderes aus. Ich denke mal du wirst ein Multitasking OS nutzen. Das Multitasking funktioniert letztendlich so das jeder Prozess für kurze Zeit ausgeführt wird, dadurch kommt es uns so vor als wenn mehrere Sachen Parallel abarbeiten.

In wirklichkeit kann aber immer nur ein "Befehl" gleichzeitig abgearbeitet werden. Und im oberen Code ist z.B. nicht sichergestellt das nach der if Überprüfung dein Programm auch noch an der Reihe ist.

Das kann zu folgendes führen. Du überprüfst ob eine Datei existiert, diese existiert nicht. Dann ist ein anderer Prozess an der Reihe, dieser erstellt jetzt auf einmal genau die Datei. Danach ist dein Programm an der Reihe und mit deinem open überschreibst du auf einmal diese Datei.

Dieser Fehler hängt also letztendlich von der Ausführungszeit ab. Deswegen nennt man soetwas auch Race Condition. Solche Fehler sind schwer zu finden.

sid burn

2007-08-05 02:46

User since
2006-03-29
1520 Artikel
BenutzerIn

user image

Fortsetzung vom vorherigen Beitrag... Teil 2 of 4

Folgende Angriffsmöglichkeit existiert z.B. bei den oberen Code. Stell dir vor du hast ein Programm geschrieben das als 'root' läuft. Jetzt möchtest du gerne eine PID Datei schreiben lassen. Und jetzt stell dir vor jemand würde genau zwischen deiner exist überprüfung und deinem open einen symbolischen Link auf /boot/vmlinuz-xxx erstellen. Dein Programm würde also den Kernel überschreiben. Beim nächsten Bott des Rechner würde der Server nicht mehr starten. Hört sich unwahrscheinlich an?

Ein Angreifer kann ein kleines Shellskript schreiben. Dieses Shellskript legt dauern einen symbolischen Link auf die Zieldatei an, und löscht ihn wieder. Die Erfolgschancen steht bei ca 50% das dieser Angriff klappt.

Im Vergleich zu sysopen() ist das allerdiengs etwas anders. Und jetzt kommen wir zu O_EXCL. O_EXCL öffnet eine Datei exclusiv. Das hat nichts mit Locking zu tun. Es bedeutet das eine Datei nur dann erzeugt wird wenn sie nicht existiert. Dieser Schritt ist atomar. Daher hier kann es nicht passieren das in der zwischenzeit ein anderer Prozess dazwischen funkt. Es kann also keine Race Condition auftreten. In diesem Sinne also sicherer.

Ansonsten kannst du mit sysopen() auch Optionen angeben ob die Datei ein symbolischer Link sein darf etc. Ebenfalls alles Atomar. Allerdiengs ist das weniger wichtig, den selben effekt kannst du auch mit open() erreichen, du musst nur eine kleinigkeit beachten.

Code (perl): (dl )

if ( -l $filename ) {
    die "Ich will kein symbolischen link\n";
}
open my $fh, '<', $filename  or  die $!;

In diesem Fall hast du auch wieder eine Race Condition, allerdiengs wenn du es so umschreibst dann nicht mehr.

Code (perl): (dl )

open my $fh, '<', $filename  or  die $!;
if ( -l $fh ) {
    die "Ich will kein symbolischen link\n";
}

Weiterführung im nächsten Beitrag...

Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

sid burn

2007-08-05 02:47

User since
2006-03-29
1520 Artikel
BenutzerIn

user image

Fortsetzung vom vorherigen Beitrag... Teil 3 of 4

Der Schlüssel ist es den Dateitest auf den Filehandle zu erledigen, und nicht auf den Filenamen. Der Filename kann sich jederzeit ändern. Ein anderer Prozess kann dazwischen kommen, die Datei löschen, etwas anderes erzeugen etc.

Wenn du allerdiengs bereits die Datei einmal geöffnet hast, dann hast du einen Filediskiptor der auf die Datei zeigt. Die Datei kann jetzt verschoben werden, sogar gelöscht werden oder andere Sachen mit ihr passieren. Dein Dateidiskriptor wird weiterhin immer auf die selbe datei zeigen. Daher überprüft "-l $fh" auch wirklich deine geöffnete Datei, auch wenn vielleicht die Datei in wirklichkeit schon verschoben wurde, oder jetzt an einem anderen Ort liegt.

Ansonsten wenn du Dateitests immer auf Filehandles erledigst gibt es da keine Probleme.

Wenn du eine Datei erstellen möchtest allerdiengs keine Datei überschreiben möchtest dann musst du sysopen() in verbindung mit den Optionen O_CREAT | O_EXCL nutzen, dass ist die einzige Option die auch sicher vor Race Conditions ist.

Ansonst beim reinen öffnen (lesend) einer Datei ist es volkommen egal ob du nun open() oder sysopen() nutzt. Auch die Aussage sysopen() an sich wäre sicherer stimmt so auch nicht.

Weiterhin kannst du eine Datei auch beliebig gemischt mit sysopen() und open() öffnen, sofern das überhaupt einen Sinn ergibt.

Ansonsten unabhängig davon kann sysopen() halt noch paar Sachen die open() nicht kann. das meiste hängt halt zusammen mit den gleichzeitigen erzeugen, oder das eine Datei nicht vorhanden sein darf. Mit O_EXCL als Modus darf eine Datei nicht vorhanden sein, und wenn du nicht O_CREAT angibst, dann wird eine Datei auch nicht erzeugt wenn sie nicht existieren sollte. So kannst du eine Datei erweitern, aber nur dann wenn sie schon existiert und paar andere Feinheiten. Ob du diese Feinheiten benötigst hängt von deinem Programm ab was du schreibst.

Fortsetzung im nächsten Beitrag...

Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

sid burn

2007-08-05 02:49

User since
2006-03-29
1520 Artikel
BenutzerIn

user image

Fortsetzung vom vorherigen Beitrag... Teil 4 of 4

Quote
Noch eine Anmerkung zu Deiner Frage "ob man das [Skript] so verwenden kann".
Also ich nehme use warnings/strict/diagnostics/usw. nur zum Testen. Für den Produktivbetrieb nehme ich das wieder raus, um böswilligen Leuten nicht unbedingt auch noch skriptinterne Infos zukommen zu lassen. (Weiß aber nicht ob das der Mainstream auch so macht.)

Wie bitte? Du nimmst "use strict;" und "use warnings;" aus einem Skript im Produktivbetrieb heraus? "strict" und "warnings" gehören immer herein, vorallem im Produktivcode.

Das einzige was man im Produktivbetrieb heraus nehmen sollte, ist "diagnostic" da es verdammt viel an zusätzliche Informationen "Meldungen" lädt man im Produktivbetrieb nicht benötigt. Daher das laden wird schneller. "strict" und "warnings" erzeugen aber keinen Overhead, sollten daher immer drin bleiben.

Aber selbst diagnostic nutze ich nicht. Da ich mit den Fehlern auch so schon genug anfangen kann, und ich die ausführlichen Meldungen von diagnostic in der Regel nicht benötige.

P.S.:
Die letzten 4 Kommentare sind von mir. Der erste Kommentar war von "Gast" weil ich leider nicht eingeloggt war. :(

Wollte man nicht die Zeichenbegrenzung erhöhen? Sind ja immer noch 2000 Zeichen als Begrenzung drin. :(

Kann es sein das die Authentifizierung mit dem Cookie nicht vernünftig läuft? Oder das Cookie oder so zu schnell ausläuft? Hatte mich letztens schon angemeldet und gesagt das über Cookie Authentifiziert werden sollte. Jetzt war ich aber wieder nicht eingeloggt.

Weiterhin sollte man als "Gast" dazu gewzungen werden einen namen einzugeben. Dann passiert so ein Fehler seltener.

Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

View all threads created 2007-08-05 00:48.