Bug 73492 - [request] Reliable Temporary Files
Summary: [request] Reliable Temporary Files
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 4.10-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-03 19:20 UTC by Ronald F. Guilmette
Modified: 2018-05-20 23:50 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald F. Guilmette 2004-11-03 19:20:20 UTC
	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.

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.
How-To-Repeat: 	Write a program containing the above code snippet, and then send it
	a SIGKILL at Just The Right Moment.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-01-28 09:05:04 UTC
State Changed
From-To: open->suspended

Mark suspended awaiting patches.
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:50:54 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"