Christopher Vance wrote:You can already mark a fd 'close on exec'.
May I suggest a different feature: the ability to mark an open file (not just its fd) 'remove on close', with permission checked at mark time rather than close time (this status forgotten if not permitted when set) and the unlink actually done at close time only if the file has exactly one link and one open file instance at that time.
If all you have is an fd, you can not get from an fd to a path without an exhaustive search of the disk, in most FS's.
I know that, but you're right that it didn't show in my previous mail.
If this thing is set at open time, rather than later, you do have a path. I guess for sanity, I would record the name to *node of immediately enclosing directory, name within directory and inode of file. That surely gives you enough at close time to determine whether the file is still where it was and is otherwise unattached.
Also, leaving the path peresent permits someone to hard-link it to some other file, to make it stay around. Since /var has a /var/tmp, this would be a real danger, I think.
We were originally talking about pid files for root-dropping servers. Assuming there's enough in there for a new still-root server to determine if its predecessor is gone, there's nothing to stop the new server removing the existing file before creating a new one for itself, which won't have bogus links until somebody finds it again.
The attacker has a link to a file no longer in use. Is the DOS disk full?
Thanks for your comment, and my opportunity to learn from it; there's clearly more thought needed.
And I know that the whole idea of setting up things to happen at a later time like this is not particularly in flavour with the rest of Unix.
Simpler alternative not requiring kernel changes:
program:
fork
if child
setup file
drop privs
do stuff
if parent
wait for child
remove fileThe post-fork parent code could be made very simple to audit by execing a program whose sole purpose is the wait/remove.
-- Christopher Vance _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
