Skip to contentSkip to conversation

Suggestion for a new system call: convert file handle to a cookie for transfering file handles between processes.)

DISCUSSION RAMON_GARCIA_F 3 participants 3 messages Jul 21, 2003 – Jul 22, 2003

lore
Share & tools
lore
#0 lore raw

Many of you have said that it is not a good thing to bloat the kernel with new system calls. But for that purpose, it is important to design the system interface in such way that primitives can be combined together to get any desired result.

This is the reason why Linux clone() is better than Solaris threads, why Unix fork()+execve() is better than Windows CreateProcess(). The former are more simple primitives. They encourage simple and thus less error prone code both in the kernel as in user space applications.

And that is exactly the reason why I like the interface that I designed. As opposed to transfer of handles through unix domain sockets, that is tied to unix sockets, my interface is more primitive. It is not tied to anything. You get a representation of a file handle, and then you can transfer it through a regular file, a pipe, ...

Ramon

#1 lore raw
Quoted 5 lines · RAMON_GARCIA_F

And that is exactly the reason why I like the interface that I designed. As opposed to transfer of handles through unix domain sockets, that is tied to unix sockets, my interface is more primitive. It is not tied to anything. You get a representation of a file handle, and then you can transfer it through a regular file, a pipe, ...

There are many arguments against it.

- Cookies are only useful on the local system, files, pipes, tcpsockets etc. are cross-platform.

- Refcounting issues, a rogue application can quickle use up kernel resources by requesting thousands of cookies, he isn't even limited by per-process resource limits, as it is possible to open a file, grab a cookie, and close the file. The only 'solution' you have is a timeout on the cookie, possibly this could be extended by some scheme where cookies are dropped more agressivly. But any such solution will either not be sufficient to protect the system from resource exhaustion or provide the opportunity for denial of service attacks.

- Technically the SCM_RIGHTS message that is passed across the socketpair(2) or Unix domain socket contains pretty much the cookie you are talking about, but it has several useful properties. The process is required to keep the filehandle open until the message is passed, so it has to obey per-process resource limits. There is strict refcounting and no workarounds required to expire handles, the SCM_RIGHTS method is portable across pretty much all Unix systems.

- It is trivial to implement your proposal in userspace based on the existing primitives (simple library + daemon solution). But it is not possible to implement the exact semantics of the existing primitives in userspace if they are replaced by your proposed cookies in the kernel.

Jan

#2 lore raw
Quoted 8 lines · Jan Harkes

- Refcounting issues, a rogue application can quickle use up kernel resources by requesting thousands of cookies, he isn't even limited by per-process resource limits, as it is possible to open a file, grab a cookie, and close the file. The only 'solution' you have is a timeout on the cookie, possibly this could be extended by some scheme where cookies are dropped more agressivly. But any such solution will either not be sufficient to protect the system from resource exhaustion or provide the opportunity for denial of service attacks.

Best of all: How big you make the number, doesn't matter: You can always guess such numbers as a local attacker. If not now, then in some years (want to recompile all existing applications then?).

cmsg(SCM_RIGHTS) is the much better solution, if you really have processes, which are neither a sibling nor a parent/child relationship.

And it's also ugly enough ;-)

Regards

Ingo Oeser