non-root process and PID files
vance at aurema.com
Thu Oct 30 15:36:46 PST 2003
On Thu, Oct 30, 2003 at 03:45:24AM -0800, Terry Lambert wrote:
>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
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
Simpler alternative not requiring kernel changes:
wait for child
The post-fork parent code could be made very simple to audit by
execing a program whose sole purpose is the wait/remove.
More information about the freebsd-hackers