> DoS your application ... randomness > Now, at a quick glance, it doesn't appear that Mutt tries to deal with > this, i.e. safe_open() does not detect failures and retry, but it > probably should make an attempt. But I didn't look at the calling > code, it may be handled there (though I think it shouldn't be).
I didn't notice a retry loop, or try to see what implications a failure might have beyond the many callers. Maybe a more generalized function and call scheme is in order. Within that, amongst whatver else was talked about, an EEXIST could be retried up to some limit. Any other error should probably exit. > at start-up, create a randomly generated temporary directory There's no guarantee that other processes of the user are not creating files in there, so any creation of your own files in there would still need to be strong as well. Likely, no, possible, yes. > There is an lstat(), which exists to establish that the target is not > a symlink. Which, being any of a family of calls one might craftily think of making before the actual file creation attempt, is again subject to race and would fail anyways... http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html If O_EXCL and O_CREAT are set, and path names a symbolic link, open() shall fail and set errno to [EEXIST], regardless of the contents of the symbolic link. > horrible, horrible idea Only if you mess it up :) CREAT EXCL, perms, randomness, returns... all part of it. The only part I didn't know was the old NFS caveat, thanks. Don't know what percent still use pre-3 NFS as far as docs go. Someone mentioned Solaris... http://illumos.org/man/3C/mkstemp Certain applications might also want to use tmpfile().
