linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Olsson <mnemo@minimum.se>
To: linux-c-programming@vger.kernel.org
Subject: Re: mktemp()
Date: Sun, 06 Jun 2004 11:50:11 +0200	[thread overview]
Message-ID: <40C2E8D3.8060102@minimum.se> (raw)
In-Reply-To: <20040605093054.A613@Imrashi.net.bd>


Imagine two processes using first mktemp() and later on open(). The 
first one checks if there a file called "abc112233" and there is no such 
file, now the second process does the same check and there is still no 
such file. Both processes now thinks its okay to use that filename.

Now two things can happen:

A) Process one writes its data to the file and closes it, followed by 
process two writing its data to the same file (overwriting it). Here the 
data written by process one is lost.

B) Process one writes and while its writing the second process tries to 
write and gets an error. Here process two doesnt get its data written.


In a server with many threads these collisions actually *do* happen in 
reality even if they seem a little obscure at first.



mvh.
/m

Progga wrote:

> 
>  Is mktemp() a deprecated function ?  The compiler ( actually the linker ) is 
> repeatedly shouting -
> 
>  "warning: mktemp() possibly used unsafely; consider using mkstemp()"
> 
> 
>  The manpage of mktemp(3) states -
> 
> -------
> A common problem that results in a core dump is that the programmer
> passes in a read-only string to mktemp(), mkstemp(), mkstemps() or
> mkdtemp().
> ------
> 
>  - and I have taken care of this.
> 
> 
>  The manpage also says -
> 
> ------
> BUGS
>      This family of functions produces filenames which can be guessed, though
>      the risk is minimized when large numbers of `Xs' are used to increase the
>      number of possible temporary filenames.  This makes the race in mktemp(),
>      between testing for a file's existence (in the mktemp() function call)
>      and opening it for use (later in the user application) particularly dan-
>      gerous from a security perspective.  Whenever it is possible, mkstemp()
>      should be used instead, since it does not have the race condition.  If
>      mkstemp() cannot be used, the filename created by mktemp() should be cre-
>      ated using the O_EXCL flag to open(2) and the return status of the call
>      should be tested for failure.  This will ensure that the program does not
>      continue blindly in the event that an attacker has already created the
>      file with the intention of manipulating or reading its contents.
> ------
> 
>  I haven't used open() and hence there's no O_EXCL.  Is it causing the warning ?
> I also can't understand how an attacker can dupe the process into writing in
> his intended file since mktemp() is supposed to return those names only that are
> currently UNUSED.
> 
> 
> 
>  Khoda Hafez
>  Progga
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

      parent reply	other threads:[~2004-06-06  9:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-05  3:30 mktemp() Progga
2004-06-05  4:55 ` mktemp() Glynn Clements
2004-06-05  8:17   ` mktemp() Progga
2004-06-05 11:16     ` mktemp() Jan-Benedict Glaw
2004-06-05 12:40       ` mktemp() Progga
2004-06-05 13:18         ` mktemp() Jan-Benedict Glaw
2004-06-05 19:42     ` mktemp() Glynn Clements
2004-06-05 22:43       ` mktemp() Progga
2004-06-06  9:50 ` Martin Olsson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40C2E8D3.8060102@minimum.se \
    --to=mnemo@minimum.se \
    --cc=linux-c-programming@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).