Exploiting symlinks and tmpfiles

Posted Sep 20, 2007 8:58 UTC (Thu) by intgr (subscriber, #39733)
Parent article: Exploiting symlinks and tmpfiles

When creating files, ensure that the open() call uses O_CREAT | O_EXCL

What about programs that use the buffered ANSI fopen() call? As far as I can tell, there is no easy and portable way to use it for atomic file creation. Using open() and fdopen() is an alternative, but again is usable on POSIX systems only.

to post comments

Exploiting symlinks and tmpfiles

Posted Sep 20, 2007 9:51 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

Indeed, why shouldn't O_CREAT and O_EXCL be the default (clunky but safe) behaviour - and if your program needs to overwrite an existing file rather than creating a new one, you can give a flag to specify this unusual behaviour.

Well, like C string functions, I guess it's too late to fix these design decisions now.

Exploiting symlinks and tmpfiles

Posted Sep 20, 2007 11:58 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Way too late. I mean, even the insecure pre-stdio gets() function is still around, decades after deprecation.

This is the downside of code reuse and common interfaces: it's very hard to change stuff once it's been widely used. (This seems to be a common trait in all sorts of complex systems: consider the degree of conservation of ancient regulatory systems in metazoan genetics, for instance, simply because once it's set up it's too hard to change. Building foundations is easy: changing them once a house is built on top is really difficult.)

Exploiting symlinks and tmpfiles

Posted Sep 20, 2007 15:05 UTC (Thu) by ken (subscriber, #625) [Link]

Thank you for the clarification. I was a bit confused but once you made the link to metazoan genetics things cleared up. :-)

No easy solution with fopen()

Posted Sep 20, 2007 14:19 UTC (Thu) by dwheeler (guest, #1216) [Link] (2 responses)

You're correct, there is NO easy solution with fopen(). I believe that there should be work to modify the standards to create an additional option character (just as "b" is a flag for "binary" on some systems), but it'd be a fair amount of work to get it through the standards process.

Actually, there is an easy solution with fopen()

Posted Sep 20, 2007 16:29 UTC (Thu) by hummassa (guest, #307) [Link] (1 responses)

I tested it on linux, works ok -- except for the fact that it WILL clobber an empty file:

  
FILE* open_only_if_does_not_exist(const char *filename) {   
  FILE* f = fopen(filename, "a");   
  if( ftell(f) ) {   
    fclose(f);   
    return 0;   
  }   
  return f;   
}

Actually, there is an easy solution with fopen()

Posted Sep 20, 2007 18:45 UTC (Thu) by vmole (guest, #111) [Link]

...except for the fact that it WILL clobber an empty file

So, in other words, it doesn't do what the function name claims. Not to mention no error checking on the fopen() call. Yeah, I know, it's just psuedo-code in a comment. But since the whole article is about correct code without security holes, I'm being a dick about it.

Anyway, it pointless to try to do this within the C standard. If you don't have POSIX calls (open(), fdopen()), then you don't have POSIX file system semantics, so you've got no guarantees anyway. For temporary files, use tmpfile(). If your OS/library doesn't have tmpfile() (which means it's not even C89), implement it using whatever OS specific tools are necessary. For non-temporary but unique files, the most general technique looks to be mkstemp() and rename(), but I'd guess plain old open()/fdopen() is just as well supported.