Mailinglist Archive: opensuse-de (4731 mails)

< Previous Next >
Re: Mit sed Zeilenende loeschen
  • From: David Haller <david@xxxxxxxxxx>
  • Date: Wed, 18 Jul 2001 23:34:55 +0200
  • Message-id: <20010718233455.A1000@xxxxxxxxxx>
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
>
>> >Wenn es nicht funktioniert, dann sollte da aber schon eine
>> >Fehlermeldung kommen. Kommt doch sonst nie einer drauf, daß es an
>> >der Nichtanlegbarkeit (was für ein Wort ;)) der Tempdatei liegt.
>
>> Hast du's getestet? Das ist naemlich Absicht, dass da nur das
>> exit 1 steht:
>
>> $ 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).

Allerdings habe ich gesehen, dass die originale Version von mktemp
durchaus auch strerror(errno) ausgibt, das hat der patch (-linux.patch)
eben ueberschrieben.

>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...

>> >Das $$ ist hier eigentlich nicht mehr nötig. mktemp macht einen
>> >Einzigartigen Namen.
>
>> Naja, "einzigartig" halt im Rahmen von mkstemp... Und "sicher"
>> ist die in mkstemp verwendete Funktion __gen_tempname nicht...
>
>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).

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);')...

>Dabei benutze ich mktemp mehrfach. Ich sollte mir mal die Tempfiles
>angeschaut haben. ;) Hmm, in einen Fall, habe ich es sogar recht
>häufig gemacht, aber nicht auf dem Namen geachtet. Der
>$0-Bestandteil hatte zum Auffinden gereicht. ;))

*g*

>Dann schlage ich sowas wie 
>
>${prg}.`date +%s`.$$.tmp vor. Da gibt es so schnell keine doppelte,
>es sei denn es werden im Prozeß selber mehere tmp angelegt. Die kann
>ich dann aber hart anders nennen, etwa:
>
>$TMP1=$TMPDIR/$PRG.A`date +%s`.$$.tmp
>$TMP2=$TMPDIR/$PRG.B`date +%s`.$$.tmp
>$TMP3=$TMPDIR/$PRG.C`date +%s`.$$.tmp
>
>Sollte man in einer Schleife Tempdateien anlegen (könnte ja sein,
>daß man das braucht. ;)) dann wird der Schleifenzähler mit im Namen
>aufgeführt.

Ack.

>> 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...

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)...

>Was mir an Deiner trap-Zeile auffällt, Du fängst Signal 14 nicht ab.

Oh, das war nur kurz hingeschludert, SIGALRM hab ich schlicht
uebersehen ;)

-dnh

-- 
>Blame directed at the wrong vendor tends to get reclassified as whining.
No worries, I'm good at that too.   -- Chris Hacking and Jay Mottern in asr

< Previous Next >