Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Nov 2017 21:00:50 +0100
From: Solar Designer <>
Subject: Re: Security risk of vim swap files

On Sun, Nov 05, 2017 at 10:15:44PM -0800, Ian Zimmerman wrote:
> On 2017-11-01 19:12, Solar Designer wrote:
> > On Wed, Nov 01, 2017 at 07:02:22PM +0100, Jakub Wilk wrote:
> > > Unfortunately, glibc's implementation of tmpfile(3), which is the
> > > most fool-proof interface for dealing with temporary files that the
> > > C library offers, doesn't honour TMPDIR. :(
> > 
> > We've been carrying a patch for this for ages:
> Do you know why this has not been changed upstream?

I did not, but to try and answer your question I just found this:

| Re: Why doesn't tmpfile() honor $TMPDIR?
|     To: Joel Klecker <>
|     Subject: Re: Why doesn't tmpfile() honor $TMPDIR?
|     From: Ulrich Drepper <>
|     Date: 29 Apr 1999 12:24:15 -0700
|     Cc:
| Joel Klecker <> writes:
| > In stdio-common/tmpfile{,64}.c, __path_search is called with the 
| > fifth argument set to 0, which causes tmpfile(), and tmpfile64() to 
| > use P_tmpdir.
| > 
| > Is there a particular reason why tmpfile() and tmpfile64() should not 
| > be changed to call __path_search with the fifth argument set to 1, so 
| > that the functions do honor $TMPDIR?
| Yes:
| - compatibility with other systems and earlier versions
| - newly introduced security risks
| > I am asking because there is a long-standing bug 
| > ( in the Debian Bug 
| > Tracking System regarding this.
| This is no bug in glibc.

In that Debian bug, we see this comment:

| From: Topi Miettinen <>
| To:
| Cc: Ian Jackson <>
| Subject: Re: Bug#12240: patch
| Date: Tue, 07 Jul 1998 23:20:08 +0300
| There are two parts in the patch, one for tmpfile() use and other for
| tmpnam().
| Regarding tmpfile(), I checked K&R, Stevens, Donald Lewine's "POSIX
| Programmer's Guide", and Solaris manual page and they all agree with glibc
| documentation in that nothing is guaranteed. Fixing this in glibc is
| trivial, by changing fifth argument of __stdio_gen_tempname call from 0 to
| 1 in stdio-common/tmpfile.c. This will cause security problems with setuid
| programs using tmpfile(), though.

Apparently, the security risks and problems mentioned are that people
were concerned this change would result in SUID programs (and/or their
children - e.g., a command run via sudo) honoring TMPDIR in their
tmpfile(3) calls - however, that is not in any way specific to
tmpfile(3), and it should be addressed for all such places in glibc
similarly.  I don't know what state glibc was in with regard to
honoring, ignoring, or unsetting TMPDIR in SUID programs in 1998-1999.
Maybe those concerns were valid at the time, but if so it means glibc
had other instances of the issue.

> Do you know of any programs that break with this change?



Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.