On Tue, Jan 04, 2011 at 08:55:41PM +0100, Olaf van der Spek wrote:
> On Tue, Jan 4, 2011 at 8:45 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > Because lots of programs expect something like
> >
> > fd = open("/tmp/foo", O_WRONLY|O_CREAT|O_EXCL);
> > unlink("/tmp/foo");
> > write(fd, "data", 4);
> >
> > to succeed. This is how Unix filesystem semantics work and pretty much
> > always have. POSIX allows unlink(2) to return EBUSY, but that's not at
> > all Unixy. The only case I can see for EBUSY is what NetBSD and OpenBSD
> > do: restrict unlinking a mount point. (This is also the only case for
> > EBUSY on Solaris, Ultrix, and HP-UX.)
>
> unlink will probably return an error, but since that's not checked,
> that snippet will succeed.
> WRONLY seems weird, what's the purpose of a snippet like this?
>
There are several reasons to do something like that. One is that in the
event of the process (or even entire OS) crashing, cleanup of the disk
space is essentially automatic, because once no open file descriptors
reference, the OS reclaims it.
Another reason to do something like that is to give you a more secure
temporary file. By adding mktemp() (or something similar) into the
example Brian gave, you can defend against attacks that depend on file
name collisions. By quickly unlinking, the file will no longer appear
in directory listings, making exploits of the data written to the file
more challenging (not impossible, just more challenging).
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature