On 25-Jun-2002 Dennis Stosberg wrote:

Seltsam. In mkstemp(3) steht wiederum:

Don't use this function, use tmpfile(3) instead. It is better defined and more portable.

Seltsam. Davon steht bei mir nichts. Liegt es an der Version? Meine ist auf den 3. April 1993 datiert. Dafuer steht in man tmpnam "Never use this function. Use mkstemp(3) instead." Beste Gruesse, Heinz. -- http://www.pahlke-online.de http://www.Pahlke-KunstWebDesign.de

h.pahlke@nexgo.de [25 Jun 2002 14:13:56 +0200 (CEST)]:

Gibt es da trotzdem eine einfache Loesung oder sind hier doch etwas tiefergehende Programmierkenntnisse erforderlich?

Da sind ein wenig Programmierkenntnisse erforderlich, denn ein einfaches Ersetzen funktioniert ja nicht. Das Problem mit tmpnam ist, dass diese Funktion ja nur einen eindeutigen Namen zurückliefert. In der Zeit zwischen Erhalt des Namens und dem dann folgenden Öffnen der Datei könnte ein böswilliger Mensch dir eine Datei mit dem Namen unterschieben. Das lässt sich nun verhindern, wenn O_EXCL|O_CREAT in den Flags für open(2) verwendet wird, da dann ein Fehler gemeldet wird, wenn die Datei existiert. Die Warnmeldung kommt allerdings vom Linker (ld) (präziser gesagt, sie ist in dem Objekt kodiert, welches tmpnam enthält und der Linker gibt nur diese Meldung aus) und der kann nicht prüfen, ob die Verwendung von tmpnam in diesem Fall nun sicher oder unsicher ist, also wird gewarnt. Philipp

Moin, * Dennis Stosberg [02-06-25 14:58]:

Am 25.06.2002 um 14:13 schrieb Heinz W. Pahlke:

...

Und fuer xpdf haben mich eben eine Reihe von Warnungen "the use of `tmpnam' is dangerous, better use `mkstemp'" ueberrascht. Einfach in den entsprechenden Dateien tmpnam durch mkstemp ersetzen, geht natuerlich nicht (habe es trotzdem sicherheitshalber mal ausprobiert). Gibt es da trotzdem eine einfache Loesung oder sind hier doch etwas tiefergehende Programmierkenntnisse erforderlich? Seltsam. In mkstemp(3) steht wiederum:

Don't use this function, use tmpfile(3) instead. It is better defined and more portable.

tmpnam(3) gibt einen eindeutigen Namen für eine temporäre Datei zurück. Ich kann mir vorstellen, dass das ein Sicherheitsrisiko ist, wenn jemand den generierten Namen der Datei kennt, und diese öffnet bzw. austauscht, bevor mein eigenes Programm dies tut. /tmp ist ja schließlich für alle beschreibbar. Öffnen kann er sie nicht, bzw. nur, wenn der Programmierer einen weiteren Fehler macht. Es kann aber eine Race Condition geben, dh. der Angreifer kann nach der Erstellung des Dateinamens eine Datei anlegen, die diesen Namen trägt. (Allerdings auch nur, wenn der Programmierer einen weiteren, schwerer zu erkennenden Fehler macht.)

mkstemp(3) gibt dagegen direkt einen Datei-Deskriptor zurück. Die Datei ist dann schon geöffnet und kann nicht mehr einfach ausgetauscht werden. Intern wird wahrscheinlich irgendwie sichergestellt, dass Erzeugen und Öffnen der Datei (vielleicht auch sofort ein anschließendes Löschen) möglichst direkt hintereinander ausgeführt werden. Das passiert atomar, dh. die Datei wird exklusiv geöffnet.

Das Problem von mkstemp(3) ist in der Manpage beschrieben: Die Datei wird in glibc 2.0.6 und früher mit Mode 0666 angelegt. Da man sich nicht sicher sein kann, welche glibc der Anwender benutzt, kann man mit tmpnam(3) eine bessere Lösing stricken. (In meiner Manpage von tmpfile(3) steht nichts über den Mode.) Thorsten -- Scully: Do you have a theory? Mulder: I have plenty of theories.

[Ich hasse es, mir selber antworten zu müssen]

Ach ja, der kleine folgende Patch könnte helfen:

Und nach dem Patch ist natürlich ein Aufruf von autoconf nötig, damit aus configure.in configure wird. Philipp

Am Son, 2002-06-30 um 21.13 schrieb Heinz W. Pahlke:

Hallo Philipp,

On 29-Jun-2002 Philipp Thomas wrote:

...

"Heinz W. Pahlke" [20020525 14:13:56 +0200]:

...

Und fuer xpdf haben mich eben eine Reihe von Warnungen "the use of `tmpnam' is dangerous, better use `mkstemp'" ueberrascht.

Also ich habe jetzt mal xpdf 1.01 gezogen und mir angesehen. Der Code in goo/gfile.c verwendet alternativ mkstemp wenn diese Funktion beim Lauf von configure gefunden wird. Da sie glibc mkstemp enthält, wundert es mich, das sie nicht gefunden wurde. Was sagt denn config.log zu mkstemp?

configure:5191: checking for mkstemp configure:5216: g++ -o conftest -g -O2 conftest.cc >&5 configure:5219: $? = 0 configure:5222: test -s conftest configure:5225: $? = 0 configure:5235: result: yes configure:5243: checking for mkstemps configure:5268: g++ -o conftest -g -O2 conftest.cc >&5 configure: In function `int main()': configure:5260: implicit declaration of function `int mkstemps(...)' ^^^^^^^^

Da steht's 'mkstemps' statt mkstemp, d.h. vermutlich Tippfehler im configure.ac/in. Ralf

Am Son, 2002-06-30 um 22.46 schrieb Philipp Thomas:

Ralf Corsepius [ 30 Jun 2002 22:06:05]:

...

...

configure:5243: checking for mkstemps configure:5268: g++ -o conftest -g -O2 conftest.cc >&5 configure: In function `int main()': configure:5260: implicit declaration of function `int mkstemps(...)' ^^^^^^^^

Da steht's 'mkstemps' statt mkstemp, d.h. vermutlich Tippfehler im configure.ac/in.

Nein, er sucht tatsächlich nach mkstemps mit 's'. Auch das gibt es (frag mich nicht wo). Unter SuSE-Linux jedenfalls nicht:

# find /usr/include -type f -name '*h' -exec grep -l mkstemps {} \; # nm -sC /lib/libc.+ | grep mkstemps # nm -sC /usr/lib/libc.* | grep mktemps

Aber der entscheidende Teil ist ja, das mkstemp gefunden wird und daher auch verwendet werden sollte. Stimmt, weiter unten aus dem config.log scheint hervorzugehen, dass er mkstemp findet.

Ralf