SUMMARY - Re: Pass an open socket to another process???

[Bill Stoltz]

Thanks to everyone who sent me mail on the passing an open socket
request.

A quick summary is that this capability does exist on 4.[23] BSD
systems, and in a more restricted environment on AT&T V.3.
We are running Ultrix 2.0 (a 4.[23] derivative) here, and I have
tested this capability and it does work.  I did not hear any
thing from anyone else (no VMS or Xenix systems) so I don't know if 
this will work on any of these system. (Maybe someone can post 
something on whether these systems support this type of system call).

The following is a summary of the responses that I received during
the last week. Again thanks to everyone who sent in a response.
At the end I will give an account of the day and a half I spent 
getting a test case working.

Most of the responses were to use sendmsg/recvmsg in 4.[23] BSD.
These calls are defined in the recv(2) and send(2) man pages.
Thanks to the explanation by several people, I was informed that the
accessrights field is actually an array of file descriptors.

Doug McCallum <ti-csl!im4u!ut-sally!violet.ico.isc.com!dougm>, explained it
the best when he said: 

> On a 4.2/4.3 BSD system, there is the concept of access rights
> passing.  It only works in the AF_UNIX domain but could be made to
> work with other protocols given a little work.  Basically, it lets you
> pass any file descriptor to another process.  It uses the AF_UNIX
> SOCK_DGRAM mechanism and is an array of int's in the structure used in
> recvmsg/sendmsg.  I've used this as a way to implement a file password
> server to allow opening a restricted access file if you knew the
> password.
> 
> It works like a "dup" across process boundaries.

Doug went on to say that this capability is a standard feature of AT&T V.3. 

> On V.3, the Streams mechanism allows a process to send a stream
> descriptor over a connected stream pipe (a stream pipe is a stream
> that connects two processes on the same machine).  Since Streams is
> protocol independent, you could implement any protocol underneath and
> have the same capability.  Note that Streams by itself isn't a
> protocol and V.3 may come with Streams but no protocols.  V.3 does
> have a stream pipe which is very simple minded and appears to exist
> solely as a way to get other streams descriptors to an unrelated
> process.
> 
> Streams is the abstraction that AT&T is using for future network
> support.
> 
> The big difference between the two mechanisms is that BSD allows any
> file descriptor and V.3 only allows streams file descriptors.

A couple people also mentioned the "inetd" or Sun inet program.  They
felt that this also provided this type of cabability.  I did not spend
much time looking into this option,  The Ultrix 2.0 inetd did not
use the sendmsg/recvmsg calls so I stopped looking at it.

Once I received all this information, I decided that I could put together 
a simple test case in a matter of hours.  Well, I found a few stumbling 
blocks along the way that I would like to let everyone know about.  Hopefully
I can help some people and save them some time.

First the send(2) and recv(2) man pages that describe the sendmsg/recvmsg
calls are VERY cryptic.  They briefly mention the parameters by name but
give you very little information on what to put in them.

To get started I took an already working program and hacked it into 
2 programs.  The first process was the main server and the second process
was basically one of the subroutines from the old server that only
sent back a datetime string.

At this point I now had to add a socket(2) and a bind(2) call to both
processes.  The socket used AF_UNIX and SOCK_DGRAM parameters.  The bind
call was a little tricky.  You have to give bind a valid Unix file name.
So, I set up both processes the same way, except for different file names.


	struct	sockaddr_un sktname;

	sc = socket(AF_UNIX, SOCK_DGRAM, 0);
	sktname.sun_family = AF_UNIX;
	unlink(path);
	strcpy(sktname.sun_path, "/tmp/test.serv");
	err = bind(sc, &sktname, sizeof(sktname));

The bind actually creates a file on the system.  The unlink is there to 
remove the socket if it already exists, so the bind can create a new one.
I don't know if this is necessary, but I noticed this in the elcsd(8) program.

The next step was to modify the server process to send the file descriptor
to the datetime process, instead of calling this subroutine to send back
the response.  The following is the code I inserted to send over the 
connection.

struct	msghdr	sktmsg;
struct	sockaddr_un sktname;
struct	iovec 	iov;
	char	buf[80];
	int	rights[1];
	int	socket2pass;

	sktname.sun_family = AF_UNIX;
	strcpy(sktname.sun_path, "/tmp/test.dt");
	iov.iov_base = buf;
	iov.iov_len = 0;
	rights[0] = socket2pass;

	sktmsg.msg_name = (caddr_t) &sktname;
	sktmsg.msg_namelen = sizeof(sktname);
	sktmsg.msg_iov = &iov;
	sktmsg.msg_iovlen = 1;
	sktmsg.msg_accrights = rights;
	sktmsg.msg_accrightslen = sizeof(rights);

	sendmsg(sc, &sktmsg, 0);

Notice several things that are not clear in the man pages.  First, you must
pass in a sockaddr structure for the name of the socket to send this too,
and the size is the size of the structure, not the length of the string name.
If you just pass in the path name and length of the string you will get errors
like "No such file or directory".  Second the iovlen is the number of iovec
structures passed in.  Also, on a send, you must provide at least one iovec
structure.  I also filled in the buffer address, but left the length at 0,
I have not tried it to see if a buffer is required, my guess is yes.

Last is the accrights.  I made the assumption that the rights worked like the
iovec structures, WRONG.  For this you give the total number of bytes
you want the kernel to read in.  You must also be sure that every value you
put into the rights array is a valid file descriptor for the sending process
or you will get back an EBADF error.

Once I got all the parameters straight it worked great.

I then changed the new datetime process to block on a recvmsg call waiting
for this new connection so I could send back the datetime string.
The following is what I added to the datetime program.


struct	iovec 	iov;
	int	rights[5];
struct	msghdr	sktmsg;
	char	buf[80];

	iov.iov_base = buf;
	iov.iov_len = sizeof(buf);
	sktmsg.msg_name = 0;
	sktmsg.msg_namelen = 0;
	sktmsg.msg_iov = iov;
	sktmsg.msg_iovlen = 1;
	sktmsg.msg_accrights = rights;
	sktmsg.msg_accrightslen = sizeof(rights);

	recvmsg(sc, &sktmsg, 0);

Since this was a test program I ignored the name on the receive side.
I setup the iovec buffer, even though I knew there was no data coming in.

The last step was to retrieve the new file descriptor and issue the
send of the datetime string.  The file descriptor was now converted to
a new unused descriptor for the datetime process.  After sending out the
string, I just closed the new file descriptor and went back to wait for the
next message.  The server also closed the connection right after the
sendmsg call.

	new_fd = rights[0];
	dt_send(new_fd);
	close(new_fd);


This has been a rather long summary of the responses I got and the
work that I have done.  I hope this helps some of the people that asked 
me for a response.

I feel very comfortable with this solution.  I am recommending to the
other people in our group to use the sendmsg/recvmsg calls as a way
to implement the passing of a socket to a non-related process.  I hope 
this will help someone, I know it has helped me.

Thanks again for the responses.

bill

-----------
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243

UUCP: 	{uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice:	(214) 995-2786