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

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

[RAMON_GARCIA_F]

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

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

[Jan Harkes]

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

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

[Ingo Oeser]

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

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

[RAMON_GARCIA_F]

I do not understand the first argument. You seem to say it is posible
to create tcpsockets between different computers while it is not useful
to pass cookies under it. I do not see any problem. Just use cookies in
the local system only.

With regard to resource limits, the solution is not too difficult. As
far as resource limits are concernted, a cookie created and not yet
destroyed should count as a file handle owned by the process and user
that created it. That is, a process cannot have more coookies opened and
 not yet consumed plus total open files than the maximum number of
process descriptors. The same for each user id. There is no need for a
new limit.

Apart from the inconvenience of sendmsg being a library function rather
than a system call, I am convinced that it would be posible to implement
unix socket descriptor passing as a library call. This is not posible
for practical reasons of backward compatibility. But that does not
demonstrate that the proposed primitive is not simpler.

Ramon