Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Subject: Re: ATRN, connection cacheing (was: ETRN too fast!)
From: Greg A. Woods (woodsweird.com)
Date: Sat Sep 30 2000 - 22:26:46 CDT

[ On Sunday, October 1, 2000 at 05:21:06 (+0400), Michael Ju. Tokarev wrote: ]
> Subject: Re: ATRN, connection cacheing (was: ETRN too fast!)
> May I ask a little question here?
> That is: how smtp server can pass open connection to another process?
> I.e. how one unix process can "send" the opened file descriptor to
> another process? (If I understand this correctly).

In some Unix systems this is done through "kernel black magic"
(W.R.Stevens words, not mine! :-) that has questionable rights to exist
in a clean system design.

The idea is that one process can open up a file (which may require
certain privileges), and then it can hand this open file descriptor off
to another process through some inter-process communications mechanism.
Traditionally the concept of descriptor passing has been called "passing
of access rights" since it can be used to allow one process access to a
file (i.e. any kind of open file, including a network connection, etc.)
that it might otherwise not have access to.

In BSD, for example, file descriptors are passed through local domain
sockets (AF_LOCAL, formerly AF_UNIX) and the sendmsg() system call with
the cmsg_type field of a "struct cmsghdr" set to SCM_RIGHTS and the data
being an integer value equal to the handle of the file descriptor to be
passed. What in effect happens is the descriptor is duplicated inside
the kernel (as if with dup(2)) and then a reference to the file table
entry that new descriptor refers to is passed through the socket() layer
in a specially tagged internal message buffer. When the message is
"received" the kernel takes it on behalf of the receiving process and
allocates a new descriptor in the receiving process's file descriptor
table and hands back to the user-level code the new integer handle to
that entry. The sender and the receiver now have a descriptor that
refers to the same open file table entry and thus share the same offset
pointer, and by implication the same access rights.

In AT&T SysVr4 there are also I_SENDFD and I_RECVFD ioctl() commands
that work across a pipe (which is usually a read/write STREAMS channel
and which may have been opened via a FIFO file in the filesystem).
Programs on SysVr4 can also use AF_LOCAL sockets too, though I believe
they are really just implemented as a STREAMS channel underneath and the
user-land socket emulation code still uses I_SENDFD and I_RECVFD to do
the actual descriptor passing.

In SunOS-5 they have a whole suite of system calls for the "doors"
facility which do essentialy the same thing (but also provide a more
primitive type of remote procedure calling facility too).

> The only way I know of is to create child process that inherit
> the fd.

Yes of course you can also pass file descriptors to another process in
this traditional way using fork(). :-)

							Greg A. Woods

+1 416 218-0098 VE3TCP <gwoodsacm.org> <robohack!woods> Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com>