Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!bernsten
From: bernsten@phoenix.Princeton.EDU (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: unlink safe before close?
Message-ID: <8201@phoenix.Princeton.EDU>
Date: 7 May 89 21:21:37 GMT
References: <755@unify.UUCP>
Reply-To: bernsten@phoenix.Princeton.EDU (Dan Bernstein)
Distribution: usa
Organization: Hmph.
Lines: 34

In article <755@unify.UUCP> rk@unify.UUCP (Ron Kuris) writes:
  [is it nonportable to unlink an fd and still use it?]

According to various UNIX standards and according to the internal
workings of the ``standard'' kernel routines (see, e.g., Bach),
it is perfectly safe. A file is removed when it is fully unlink()ed
*and* fully close()d; link() and unlink() do not affect file behavior
after an open().

> The intent is to create a temporary file that noone else
> can conflict with, and is automatically removed when the program
> terminates (either normally or abnormally):

Almost, but not quite. Before the creat(), the only way that someone
else can conflict with your operations is by guessing your filename;
this is reasonably easy to deal with. After the unlink(), no other
process (other than later children) can do anything to the file,
*as long as it has no remaining links*. That last assertion is the
tricky part; if someone makes an extra link to your file between
creat() and unlink(), then the file will still have the new link
and won't disappear after your close(). You can detect this situation,
but curing it is very difficult: there is no way to find the new link,
let alone to remove it if its directory is unwritable! A sufficiently
determined user can start filling the filesystem with your old files
in this manner.

Although creat()-unlink() is the closest we have right know to a
real fdopen(char *directory), it does not exactly do the job from
a security viewpoint. (By the way, fdopen() must take an argument
to determine the appropriate filesystem; I think a directory should
be specified and require write permission, so that users can't
fill up filesystems with fdopen() that they can't fill up otherwise.)

---Dan Bernstein, bernsten@phoenix.princeton.edu