From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 3 19:20:20 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EA6616A4CE for ; Wed, 3 Nov 2004 19:20:20 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60BAA43D53 for ; Wed, 3 Nov 2004 19:20:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id iA3JKKVI039533 for ; Wed, 3 Nov 2004 19:20:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iA3JKKPt039532; Wed, 3 Nov 2004 19:20:20 GMT (envelope-from gnats) Resent-Date: Wed, 3 Nov 2004 19:20:20 GMT Resent-Message-Id: <200411031920.iA3JKKPt039532@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Ronald F.Guilmette" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E56EB16A4CE for ; Wed, 3 Nov 2004 19:18:06 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 974B643D39 for ; Wed, 3 Nov 2004 19:18:06 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: by segfault.monkeys.com (Postfix, from userid 1237) id 7060C54C9; Wed, 3 Nov 2004 11:18:06 -0800 (PST) Message-Id: <20041103191806.7060C54C9@segfault.monkeys.com> Date: Wed, 3 Nov 2004 11:18:06 -0800 (PST) From: "Ronald F.Guilmette" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 cc: rfg@monkeys.com Subject: kern/73492: Wanted: Reliable Temporary Files X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Ronald F.Guilmette" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 19:20:20 -0000 >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: