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
On Mon, Jul 21, 2003 at 07:04:29PM +0200, RAMON_GARCIA_F wrote:
> 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
On Mon, Jul 21, 2003 at 01:27:06PM -0400, Jan Harkes wrote:
> - 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