Date: Wed, 3 Nov 2004 11:18:06 -0800 (PST) From: "Ronald F.Guilmette" <rfg@monkeys.com> To: FreeBSD-gnats-submit@FreeBSD.org Cc: rfg@monkeys.com Subject: kern/73492: Wanted: Reliable Temporary Files Message-ID: <20041103191806.7060C54C9@segfault.monkeys.com> Resent-Message-ID: <200411031920.iA3JKKPt039532@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 73492 >Category: kern >Synopsis: Wanted: Reliable Temporary Files >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Nov 03 19:20:20 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Ronald F. Guilmette >Release: FreeBSD 4.10-RELEASE i386 >Organization: Infinite Monkeys & Co. >Environment: System: FreeBSD segfault.monkeys.com 4.10-RELEASE FreeBSD 4.10-RELEASE #0: Wed Oct 27 13:02:03 PDT 2004 rfg@segfault.monkeys.com:/usr/src/sys/compile/rfg20041027 i386 >Description: Consider the following code to create a "temporary" file which, it is hoped, will be removed entirely from the file system upon program completion, or upon the last close of the associated open fd, which- ever comes first: fd = open (tempfile_path, O_CREAT|O_RDWR, 0600); unlink (tempfile_path); In general, this code sequence will be sufficient to insure that the created temporary file will be removed from the file system upon the final close of the associated fd. The temporary file may perhaps _not_ be removed however in cases where a signal is received between the time the file is actually created, and the time the unlink becomes effective. This problem may be mitigated somewhat by blocking all blockable sig- nals just before the call to open() and then unblocking them all again just after the call to unlock(). The problem with this solution how- ever is that the kernel prevents SIGKILL from being blocked by a user- land program. Thus, if a SIGKILL is received between the time the file is created and the time the unlink() becomes effective, the ``temporary'' file will remain in existance, thereby polluting the file system with undesirable cruft. >How-To-Repeat: Write a program containing the above code snippet, and then send it a SIGKILL at Just The Right Moment. >Fix: This is a Request For Enhancement. In my opinion, it would be Very Very Nice to have a new O_* option bit which could be passed to the open(2) kernel primitive. One possible sensible name for such a new option would be `O_UNLINK'. The effect of such a new option would simply be to cause the kernel to unlink the file from the file system (if permitted, based on the permissions of the containing directory, and upon the UID of the process that called open() with this new O_UNLINK option) either (a) immediately, as soon as the open has been successfully completed, or else (b) at the time of the last close of the relevant fd. P.S. The justification for the proposed O_UNLINK option is essentially identical to the justification for the O_EXLOCK and O_SHLOCK open(2) options -- Here again we have a case where it is clearly useful to have an additional operation applied to the file, atomically (at least as far as userland processes are concerned) at the time of the file open operation. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041103191806.7060C54C9>