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

Hello.

I suggest to add a new system call for transfering a file handle between two processes.

In Linux, transfer of file handles can be done through a Unix domain socket. This mechanism is quite unflexible. It requires that the two applications connect by this kind of socket, and it is difficult to use from shell scripts.

The new mechanims proposed is more flexible.

A cookie is a large integer number (160 bit suggested) that can be used to refer to a file handle from any process. It is randomly choosen by the kernel at creation time. Afterwards, any process that knows this cookie can convert it back to a file handle. When this conversion is done, the cookie dies and is no longer valid.

An example of why cookies are useful.

Let cdwritter be a program for writting CDs. Unlike other programs, cdwritter is rationally designed. It is a server process that listens through a named pipe, thus making it easy to write either command line or graphical interfaces that use its functionality. The named pipe is called /var/run/cdwritter

To keep this discussion simple, cdwritter supports writting a single file (usually an ISO image) to a cdrecorder. The user gives a command, and afterwards the CD is burned. To write a file, the user must write a string "write <cookie>" to /var/run/cdwritter. The cookie is used to identify the file.

An alternative would be that cdwritter accepts a file name instead of a cookie. But then, the author of cdwritter would have to check if the user has permission to access the file. This makes cdwritter more error prone.

Shell scripts can write CDs to cdwriter. The command get_cookie, opens a file given on the command line and prints a cookie on stdout. Thus a shell script for burning the image my_nude_photos.iso would be:

echo "write $(get_cookie my_nude_photos.iso)" > /var/run/cdwritter

CREDITS: The Plan9 operating system provided inspiration for this idea.

Ramon

Hi Ramon,

Calling this tool simply with an argument (eg. CD to write) and accepting commands from stdin, outputting status info on stdout and errors on stderr is even simpler and requires no API changes ;-)

With my suggested change this is done implicitly.

But with that cookie suggestion in place, to remove the ability for fds to be reference countable, since the user can build circular dependencies now, which he for now can just do with AF_UNIX sockets.

Regards

Ingo Oeser

Do unix(7) sockets with cmsg(UCM_RIGHTS) not give you what you want?

You can have a cookie process sitting in user space waiting on a UNIX socket. When somebody passes you the right cookie string, you send them a file descriptor.

mark

P.S. I had to look a bit for cmsg(UCM_RIGHTS). I was more familiar with
ioctl(I_SENDFD), which it appears that Linux does not implement.

[email protected]/[email protected]/[email protected] __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

In article <[email protected]>,

Why, write a small program 'passfd /var/run/socket fd1 fd2' which does the work for you.

You can get the uid/gid on the other side of a unix socket easily, so you just setfsuid() / open(). But again you do need to use a Unix socket, not a pipe, so you need a small client program.

There have been patches to the kernel to treat an open() on a unix socket as a bind() + connect(), but unfortunately that has never been integrated in mainline.

Now that we have getsockopt(SO_PEERCRED, &ucred) the above would be very useful.

Mike.