Messages in this thread | | | From | (Alan Cox) | Subject | Re: FD_CLFORK or equivalent? | Date | Tue, 4 May 1999 20:46:14 +0100 (BST) |
| |
> where only the process that opened a device can have a copy > of that fd, i.e. I want the fd closed on fork().
Ok. That is normally user space policy so it isn't easy to do. User space programs set a flag to indicate a file will be closed. You could set this yourself but a malicious application could then reset it. That would depend if the item is one of security or avoiding accidents.
> I'm using fds opened on my driver to track and communicate with > participating processes, and am *relying* on a close() on that > fd to indicate that that process has died.
2.2.x will call the flush() handler when any task using the handle closes a copy of it, and the release handler on the final close.
> The problem is that when a process forks and exits, the child > will still have the fd open, so my module won't know that the > original process that opened the fd is dead, and it needs to > know so that it can unblock any processes that have blocked > on a Send() or Receive() to it.
I wonder whether you should simply allow the user to shoot themselves like this. There must be cases where one day it will be useful for your API to allow file handles to be passed on to other tasks. Making your API unUnixlike is perhaps dangerous too ?
If you are simply trying to avoid accidentally passing the handle on then the fcntl F_SETFL interface is designed to allow you to set FD_CLOEXEC in these cases as user space policy. Many security programs make heavy use of this when running unpriviledged subtasks for example.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |