* David Haller schrieb am 18.Jul.2001:
On Mit, 18 Jul 2001, Bernd Brodesser wrote:
* David Haller schrieb am 18.Jul.2001:
On Die, 17 Jul 2001, Bernd Brodesser wrote:
* David Haller schrieb am 17.Jul.2001:
On Mon, 16 Jul 2001, Jan Trippler wrote:
On Mon, 16 Jul 2001 at 19:39 (+0200), David Haller wrote:
> tmp_datei="`mktemp /tmp/${prg}.$$.XXXXXX`" || exit 1
$ mktemp /root/${prg}.$$.XXXXXX Cannot create temp file /root/.12760.YTRUBd
Ich mache meine Fehlermeldung lieber selber. Was soll der Endanwender mit obiger Meldung anfangen?
Du weisst ja auch nix genaues (Rechte, Disk voll, uebergeordnetes Verz. existiert nicht)... Du weisst du dass es nicht geklappt hat (mkstemp liefert nur 1 als exit-status).
Das ist richtig. Aber wenn ich mktemp in einer Anwendung benutze, die wiederum von einem anderen Skript benutzt wird, dann kann der Endanwender nichts damit anfangen, daß mktemp nicht funktioniert. Welches mktemp?
Der weiß doch gar nicht was ein tempfile ist. Auch hier ist perl flexiebler.
Das mag sein. Und ich denke die beste Loesung ist eh, die Meldung von mktemp (samt strerror(errno) wg. dem Grund, s.o) auszugeben, und dann zusaetzlich evtl. noch eine eigene... Aber das haengt natuerlich auch stark von dem Umstaenden ab, in denen die temporaere Datei benoetigt wird...
Klar, allerdings, wenn es sich nur um so ein Miniwegwerfskript handelt, dann benutze ich erst gar nicht mktemp. Wenn es sich aber um ein Skript für den ständigen Gebrauch handelt, dann werde ich auch selber in einem Jahr nicht mehr wissen, wie und wo da mktemp benutzt wurde. Geschweige ein Anderer.
Mist. Habe ich nicht ausprobiert. Ich kannte mktemp bisher nur so, daß es a$$.tmp oder so ähnlich ausgab. Sollte genau dies schon existieren, so gab es b$$.tmp aus usw. Halte ich für viel vernünftiger.
Nein, mktemp macht mittels der libc-Funktion 'mkstemp' (siehe die manpage dazu), aus "VORLAGEXXXXXX" ein "VORLAGEZZZZZZ" wobei ZZZZZZ das generierte "eindeutige" Muster ist (aus a-z A-Z 0-9).
Ich meinte den XXXXX-Teil. Das mit der VORLAGE habe ich auch so in Erinnerung.
mkstemp wiederum verwendet die (libc-interne) posix-funktion __gen_tempname um aus das sechststellige Muster zu erzeugen, mit dem das XXXXXX in der Vorlage ersetzt wird.
Wichtig ist doch, daß mktemp überprüft, ob der vorgeschlagene Dateiname schon existiert oder nicht. Wenn es das nicht tut, dann ist es nicht zu gebrauchen.
Tut es. Es scheitert dann (bzw. mkstemp(3) scheitert und gibt in errno EEXIST ("File exists" bzw. "Die Datei existiert bereits") zurueck. Leider gibt die gepatchte Version von mktemp diese Fehler- ursachen weder aus noch weiter (z.B. mittels 'exit(errno);')...
Ägypten? Ich erwarte von mktemp, daß wenn es feststellt, daß der von ihm gewählten Namen schon existiert, einfach einen anderen nimmt. Solange bis es einen gefunden hat.
Kryptographisch "sicher" ist das IMO nicht.
Was hat das mit Kryptographie zu tun? Auch wenn es echte Zufallszahlen sind, wird Gleichheit nicht ausgeschlossen.
Naja, um die Gleichheit geht es auch nicht (es gibt fuer das Muster immerhin 62^6 = 56.800.235.584 Moeglichkeiten). Das Problem ist, wie das Muster erzeugt wird (d.h. mit welchem Aufwand es zu vorherzusagen ist...) Und da ist das "clevere" Schema das in __gen_tempname verwendet wird nicht sonderlich, Es heisst:
==== /* Get some more or less random data. */ __gettimeofday (&tv, NULL); value += ((uint64_t) tv.tv_usec << 16) ^ tv.tv_sec ^ __getpid (); ====
d.h. es wird die Zeit (theoretisch auf die Mikrosekunde) genau und die PID verwurstet. Allerdings sind beide Datenquellen nicht als "zufaellig" einzustufen. Die PID laesst sich sowieso leicht heraus- finden und die Zeit, zu der das __gettimeofday() aufgerufen laesst, laesst sich (vermute ich) mit tests ebenfalls (hinreichend) genau vorhersagen. Das restliche Verwursten dieser Daten ist dann einfach.
Besser waere es wohl, sich die 64 bit Daten aus /dev/random zu besorgen, aber /dev/random ist halt (AFAIK) nicht im POSIX Standard... (Siehe dazu /usr/src/linux/drivers/char/random.c (den Anfangskommentar) und man 4 random).
Das "sicher" bezieht auf die Vorhersagbarkeit...
Was ist schlimm an Vorhersagbarkeit? Was ich will ist Einzigartigkeit. Das ist wichtig. Wenn ich eine Datei temp1 nenne, die nächste temp2 usw. so ist das absolut vorhersehbar, aber es ist Einzigartig, genau das was ich will. Allerdings müßten alle Programme, die temporäre Dateien benutzen dieses Schema benutzen.
Wolfgang koennte zu den Folgen der (von mir vermuteten Vorhersagbarkeit) noch einiges mehr sagen...
Aber wie gesagt, ich denke, dass die (Nicht-)Vorhersagbarkeit von __gen_tempname (und somit von mkstemp(3) und mktemp(1)) fuer die meisten Faelle ausreicht (also schwierig genug ist)...
Ich verstehe immer noch nicht, was da so schlimm dran sein soll. Was kann der Angreifer machen, wenn er weiß, wie die nächste temporäre Datei heißt? Er darf natürlich von Anfang an keine Schreibrechte darauf haben. Am Besten auch keine Leserechte. Wenn diese Datei schon existiert, wird sie nicht angelegt, sondern ein anderen Namen gewählt. Also kann der Angreifer da auch keine Fallen aufbauen. Habe ich da was übersehen? Vielleicht den kurzen Moment, der vom Test auf Existenz bis zur tatsächlichen Anlegung vergeht? Aber das Problem habe ich immer. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11