Hallo, da ich fuer das aktuelle xpdf kein fuer die Suse 7.1/7.2/7.3 geeignetes rpm-Paket finden konnte, habe ich es kurzerhand selbst kompiliert. Und das ist ja manchmal wirklich gut, weil man dann eben doch besser mitbekommt, wie gut oder schlecht Programme geschrieben sind. 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? Beste Gruesse, Heinz. -- http://www.pahlke-online.de http://www.Pahlke-KunstWebDesign.de
Am 25.06.2002 um 14:13 schrieb Heinz W. Pahlke:
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. 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. -- Dennis Stosberg eMail: dennis@stosberg.net pgp key: http://stosberg.net/dennis.asc icq: 63537718
On 25-Jun-2002 Dennis Stosberg wrote:
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
Am 25.06.2002 um 15:52 schrieb Heinz W. Pahlke:
Das Datum der mkstemp-Manpage ist der 23.12.2001. Gehört zur glibc-2.2.5 auf Debian Woody.
Dafuer steht in man tmpnam "Never use this function. Use mkstemp(3) instead."
Die tmpnam-Manpage ist bei mir vom 14.6.1999 und verweist ebenfalls auf tmpfile: BUGS Never use this function. Use tmpfile(3) instead. MfG, Dennis -- Dennis Stosberg eMail: dennis@stosberg.net pgp key: http://stosberg.net/dennis.asc icq: 63537718
Moin, * Dennis Stosberg <stosberg@gmx.de> [02-06-25 14:58]:
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.
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
"Heinz W. Pahlke" <h.pahlke@nexgo.de> [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? Ich würde einfach mal 'make distclean' aufrufen und dann nochmal erneut configure aufrufen. Ach ja, der kleine folgende Patch könnte helfen: --- configure.in.old Tue May 21 08:40:09 2002 +++ configure.in Sat Jun 29 03:51:42 2002 @@ -4,6 +4,10 @@ AC_INIT(xpdf/xpdf.cc) AC_CONFIG_HEADER(aconf.h) +dnl define unconditionally + +AC_DEFINE(_GNU_SOURCE) + dnl ##### Optional features. AC_ARG_ENABLE(a4-paper, [ --enable-a4-paper use A4 paper size instead of Letter for --- aconf.h.in.old Tue May 21 08:40:09 2002 +++ aconf.h.in Sat Jun 29 03:50:22 2002 @@ -7,6 +7,13 @@ #ifndef ACONF_H #define ACONF_H + +/* + * Define to get GNU extensions on systems that support them */ + */ + +undef _GNU_SOURCE + /* * Use A4 paper size instead of Letter for PostScript output. */ Philipp
Hallo Philipp, On 29-Jun-2002 Philipp Thomas wrote:
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(...)' configure:5271: $? = 1 configure: failed program was: #line 5248 "configure" #include "confdefs.h" #include <stdlib.h> #include <unistd.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { mkstemps("foo", 0); ; return 0; } configure:5287: result: no [...] xpdf_cv_func_mkstemp=yes xpdf_cv_func_mkstemps=no [...] #define HAVE_MKSTEMP 1
Ich würde einfach mal 'make distclean' aufrufen und dann nochmal erneut configure aufrufen.
Duerfte aber nichts sinnvolles bringen, so lange hier die glibc 2.2.4-40 und glibc-devel 2.2-9 installiert sind.
Vielen Dank. Probiere ich die naechsten Tage gleich aus, wenn ich auf Kernel 2.4.x und glibc-devel 2.2.4-40 geupdatet habe. Beste Gruesse, Heinz. -- http://www.pahlke-online.de http://www.Pahlke-KunstWebDesign.de
participants (5)
-
Dennis Stosberg -
Heinz W. Pahlke -
Philipp Thomas -
Ralf Corsepius -
Thorsten Haude