Re: [Bug-gnulib] mkstemp

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



James Youngman wrote:

|On Tue, Aug 19, 2003 at 04:53:41PM -0400, Derek Robert Price wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>mkstemp.m4 currently checks via AC_TRY_RUN that mkstemp can create 30
|>consecutive files.  Would it be reasonable to want to check that one has
|>mode 0600?  This is the current comment and handling in CVS:
|>
|>~   . . .
|>~        if (fp == NULL) free (fn);
|>~    #if (__GLIBC__ - 0 < 2 || __GLIBC__ - 0 == 2 && __GLIBC_MINOR__ - 0
|>== 0)
|>~        /* mkstemp is defined to open mode 0600 using glibc 2.0.7+ */
|>~        else chmod (fn, 0600);
|>~    #endif /* GLIBC API version <= 2.0 */
|
|
|Does the affected version of mkstemp() use an initial mode which is
|too lax, or one which is too restrictive?  If the former, you should
|probably call ftruncate() on the file after calling chmod() just in
|case the race condition has been taken advantage of.


Apparently too permissive.  I just checked the history of the
sysdeps/posix/tempname.c file from glibc and found that the file mode
changed from 0666 to 0600 between file revision 1.26 & 1.27.

Anyhow, is ftruncate, or anything at all, really sufficient to avoid a
race exploit?  I just tried the following:

Case 1:
Window 1                        Window 2
$ while true; do echo a; done >tmp      $ echo b >tmp
$ <ctrl>-c

Case 2:
Window 1                        Window 2
$ while true; do echo a; done >tmp      $ echo b >>tmp
$ <ctrl>-c

In case 1, vim displays the contents of tmp as:

b
address@hidden@address@hidden@...
a
a
a
a

Where `...' includes a long series of the ^@ characters, whatever they
represent.  The number of ^@ characters in the file seems to vary
depending on the length of time I let the first while loop run before I
run the `echo b >tmp' command.

In case 2, vim (and grep) show no `b' in tmp at all.

It seems to me that ftruncate() would not affect the contents of file
`tmp' in either case.


|>Has anyone heard of similar broken mkstemp implementations or is it only
|>GLIBC?  I haven't found anything recent in the archives.
|
|
|No, the only mkstemp() problem I know of is a bug in the previous
|version of the POSIX standard where the example usage was wrong.
|
|Other broken but not similar implementations inclulde :-
|http://docs.freebsd.org/cgi/getmsg.cgi?fetch=496565+0+archive/2002/freebsd-bugs/20020526.freebsd-bugs
|
|http://groups.yahoo.com/group/gnu-win32/message/3413?source=1
|
|http://mail-index.netbsd.org/current-users/1996/07/17/0016.html


Perhaps it is silly to be working around bugs in glibc this old?  It was
fixed January 11, 1999.  One could hope that the sysadmin in charge of
the system on which CVS is being compiled has read the appropriate
security notices and updated to a more recent version of glibc.  Then
again an extra chmod is pretty cheap.  Even if there is a potential for
a race exploit, at least that is likely slightly harder to exploit than
all tmp files remaining mode 0666.

Any data or opinions on this you could share with me?

Derek

- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
Spitwads are not free speech.
Spitwads are not free speech.
Spitwads are not free speech...

~          - Bart Simpson on chalkboard, _The Simpsons_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/UWvLLD1OTBfyMaQRAnUOAJ93SerNfKnVmXD/mO0GWUcrufu3+gCdFCCh
BG44TAmhHaRSYlU+tWjWndE=
=Ht4Y
-----END PGP SIGNATURE-----