[ On Monday, July 14, 2003 at 16:19:21 (+0200), Matthias Buelow wrote: ]
The behaviour you described is invalid, but that's not the real issue.
I really don't want to sound condescending, but I do get the distinct
feeling that you don't really understand the underlying reason why
funlink() is desirable in the first place.
The underlying goal of having a system call that can unlink a file when
given a file descriptor open on that file is to avoid an unfortunately
common insecure programming technique commonly called a "Time-Of-Check,
Time-Of-Use (TOCTOU) race condition". Calls to unlink() are vulnerable
if they are passed the fully qualified pathname of a file that was
created in or under an insecure (i.e. world-writable) directory, even if
that path is checked for vulnerabilities and the file's metadata is
compared to that of the originally created file before the unlink() call
is made. Implementing funlink() in userland would simply move the race
condition to a new place and thus be no fix at all. However a
system-call implementation of funlink() could ensure the new race
condition is impossible, thus ensuring the functionality fulfils the
underlying requirements.
Indeed it would be dangerous to imply that a userland implementation of
funlink() could do something that, as a userland implementation, it most
certainly could not possibly do.
As we've explored funlink() doesn't make sense as solution for unix-like
systems for very different and far more practical reasons, and it is the
explanation of those reasons that leads to learning what must be done
instead and how the alternatives could be optimized.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
