nicht angemeldet
.htpasswd datei schützen,wenn nur gelesen wird?
hallo, Ich habe ein cgi-script geschrieben, als login seite und würde gern wissen ob man eine .htpasswd datei schützen sollte wenn sie von dem cgi script nur geöffnet und gelesen wird ?
$Zugriffe = 0; open(FILE,"<$htpasswd") || &Dead('Cannot open file'); while (<FILE>){ /$username:$crypted/ ? $Zugriffe = $Zugriffe + 1 : $Zugriffe = $Zugriffe; }
close (FILE) || &Dead('Cannot close file');
Wenn ja wie müsste man sie schützen? Grüsse vom Alain-- ...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre
-
Hallo,
Ich habe ein cgi-script geschrieben,
als login seite und würde gern wissen ob man eine
.htpasswd datei schützen sollte wenn sie
von dem cgi script nur geöffnet und gelesen wird ?http://www.perldoc.com/perl5.8.0/pod/func/flock.html
Wenn du eine Datei zum lesen öffnest, dann solltest du normalerweise einen Shared Lock dazu anfordern. Das bedeutet dann, dass andere Prozesse die Datei auch lesen kann, aber während du am lesen bist kann keiner die Datei verändern.
Im Quellcode einfach ein
use Fcntl ':flock'; # import LOCK_* constantsund ein
flock FILE, LOCK_SH or die "Locking failed: $!";direkt nach dem open.
Viele Grüße,
Stefan
-
hallo,
Wenn du eine Datei zum lesen öffnest, dann solltest du normalerweise einen Shared Lock dazu anfordern. Das bedeutet dann, dass andere Prozesse die Datei auch lesen kann, aber während du am lesen bist kann keiner die Datei verändern.
Im Quellcode einfach ein use Fcntl ':flock'; # import LOCK_* constants
und ein flock FILE, LOCK_SH or die "Locking failed: $!";
direkt nach dem open.
Sieht das dann in etwa so aus?
$Zugriffe = 0; open(FILE,"<$htpasswd") || &Dead('Cannot open file'); flock(FILE,1) || &Dead('Locking failed'); while (<FILE>){ /$username:$crypted/ ? $Zugriffe = $Zugriffe + 1 : $Zugriffe = $Zugriffe; }
close (FILE) || &Dead('Cannot close file');
Besten dank schon jetzt für den tip . Grüsse vom Alain
--
...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre-
hallo,
Wenn du eine Datei zum lesen öffnest, dann solltest du normalerweise einen Shared Lock dazu anfordern. Das bedeutet dann, dass andere Prozesse die Datei auch lesen kann, aber während du am lesen bist kann keiner die Datei verändern.
Aber das wär auch nicht weiter schlimm,wenn die datei während dem lesen geändert wird, weil es könnte ja sein dass ein anderes cgi gerade mal ein neues user:password in die htpasswd reinschreiben will und dann wäre ein blockiren dieser datei nicht das beste . Das andere cgi hat priorität (löschen von passwörtern oder hinzufügen)
Grüsse vom Alain
--
...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre-
Hallo,
Aber das wär auch nicht weiter schlimm,wenn die datei während dem lesen geändert wird,
weil es könnte ja sein dass ein anderes cgi gerade mal ein neues user:password in die htpasswd reinschreiben will
und dann wäre ein blockiren dieser datei nicht das beste .
Das andere cgi hat priorität (löschen von passwörtern oder hinzufügen)Ich würde an deiner Stelle schon ein gescheites Locking implementieren. Vor allem, da du jetzt erwähnt hast, dass ein anderes Script auch in die Datei schreiben soll.
Ein Konflikt ist denke ich mal recht unwahrscheinlich (ich denke mal dein Script wird nur recht selten aufgerufen um die Datei zu administrieren), aber wenn du von vorneherein sauber programmierst, dann hast du später keine Probleme.
Das Script, welches die Datei beschreiben soll muss einen LOCK_EX verwenden. Dabei ist darauf zu achten, dass die Datei während des ganzen Vorgangs nicht geschlossen wird.
Ansonsten könnte z.B. folgendes passieren, wenn zwei Einträge aus der Datei gelöscht werden sollen.- Script 1 liest die Datei in ein Array (oder so)
- Script 1 löscht seinen Eintrag
- Währenddessen liest Script 2 die Datei
- Script 1 schreibt die neue Datei ohne den gelöschten Eintrag
- Script 2 löscht seinen Eintrag und schreibt sein Array in die Datei (ebenfalls ohne seinen Eintrag)
Der Eintrag den Script 1 löschen sollte ist jetzt wieder da, da Script 2 die Datei gelesen hatte bevor Script 1 sie verändern konnte.
Es kann auch passieren, dass beim gleichzeitigen lesen und schreiben unvorhergesehens auftritt. Wenn ein Script die Datei verändert, während ein anderes noch am lesen ist, würde es mich nicht wundern, wenn das lesende Script plötzlich Mist zurückliefert. (Es kann ja sein, dass oben ein Eintrag rausgelöscht wurde und der Pointer zwischen zwei Lesevorgängen plötzlich nicht mehr da steht, wo man ihn erwartet.)
Um all das zu vermeiden musst du locking implementieren. Und zwar in allen deinen Scripten welche auf die Datei zugreifen.
(Stell dir mal vor du wurschtelst unglücklicherweise gerade dann was in der Datei rum, wenn dein Server am lesen ist...)Viele Grüße,
Stefan
-
hallo,
Es kann auch passieren, dass beim gleichzeitigen lesen und schreiben unvorhergesehens auftritt. Wenn ein Script die Datei verändert, während ein anderes noch am lesen ist, würde es mich nicht wundern, wenn das lesende Script plötzlich Mist zurückliefert. (Es kann ja sein, dass oben ein Eintrag rausgelöscht wurde und der Pointer zwischen zwei Lesevorgängen plötzlich nicht mehr da steht, wo man ihn erwartet.)
Um all das zu vermeiden musst du locking implementieren. Und zwar in allen deinen Scripten welche auf die Datei zugreifen. (Stell dir mal vor du wurschtelst unglücklicherweise gerade dann was in der Datei rum, wenn dein Server am lesen ist...)
Ok danke Stefan,für diese Jnfo. Das LOCK_UN muss ich ja nicht verwenden wenn ich LOCK_SH verwende oder? Da gibts noch eine seek funktion,was heisst denn das? Ich habs jetzt so geschrieben:
use Fcntl ':flock'; $Zugriffe = 0; open(DATEN,"<$htpasswd") || &Dead('Cannot open file'); flock(DATEN,LOCK_SH) || &Dead('Locking failed'); while (<DATEN>){ /$username:$crypted/ ? $Zugriffe = $Zugriffe + 1 : $Zugriffe = $Zugriffe; }
close (DATEN) || &Dead('Cannot close file');
Grüsse vom Alain
--
...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre-
Hi,
use Fcntl ':flock';
$Zugriffe = 0;
open(DATEN,"<$htpasswd") || &Dead('Cannot open file');
flock(DATEN,LOCK_SH) || &Dead('Locking failed');
while (<DATEN>){
/$username:$crypted/ ? $Zugriffe = $Zugriffe + 1 : $Zugriffe = $Zugriffe;Sollte nicht LOCK_EX verwendet werden? So kann ja immer noch gelesen werden. Ich würde auch das verbieten wollen, damit nicht wenn du schreibst, die inkorrekten Daten gelesen werden.
mfg Andres Freund
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|-
hallo,
Sollte nicht LOCK_EX verwendet werden? So kann ja immer noch gelesen werden. Ich würde auch das verbieten wollen, damit nicht wenn du schreibst, die inkorrekten Daten gelesen werden.
Nö dieses cgi-perl script liest nur die htpasswd datei durch um zu checken ob der user.pass vorhanden ist, das ist alles.Zum schreiben und löschen von passes sind andere zwei perl-cgi zuständig.
Grüsse vom Alain
--
...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre-
Hi,
Nö dieses cgi-perl script liest nur die htpasswd datei durch um zu checken ob der user.pass vorhanden ist,
das ist alles.Zum schreiben und löschen von passes sind andere zwei perl-cgi zuständig.Achso, ich dachte du schreibst ein Script mit dem du alle Aufgaben gleichzeitig erledigen kannst.
mfg Andres Freund
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|-
hallo,
Achso, ich dachte du schreibst ein Script mit dem du alle Aufgaben gleichzeitig erledigen kannst.
Ja das hat mind. zwei Gründe,warum ich dieses login.cgi schrieb:
-
Um unnötige Manipulationen (z.B. add user=blabla)am perl.cgi auszuschliessen,wobei das beim anderen cgi auch nicht möglich sein sollte.
-
Man muss nicht wissen wo sich der htaccess geschütze bereich befindet,dies z.B. um hackerTools wie accessdiver oder bruteforce attacken zu vereiteln.
-
Bei Anmeldung mit erfolg wird der user direkt in den geschützten bereich weiter geleitet ohne dass er sich ein zweites mal anmelden muss über htaccess.
Sind nicht viele gründe aber dennoch sehr wichtige finde ich jedenfalls.
Grüsse vom Alain
--
...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre -
-
-
-
-
-
-
-