AF_UNIX + SOCK_DGRAM

[James T. Dennis]

Donn Cave <donn at u.washington.edu> wrote:
> Quoth "James T. Dennis" <jadestar at idiom.com>:

> |  I was playing with the socket module and Unix domain sockets,
> |  trying to make it work with SOCK_DGRAM.  I could get messages
> |  recvfrom() but any attempt to send responses was failing, 
> |  complaining about the return address.

> |  Now I think I understand the problem.  The recvfrom() tuple
> |  does contain two parts (which WOULD BE address and data in UDP)
> |  but I'm guessing that the address is meaningless for Unix 
> |  domain sockets.  It occurs to me that the "return" address 
> |  must be the same socket (filesystem node of type 's') as the 
> |  one that I did a .bind() to.  

> Actually think you have run into a bug in Python's socket module.
> If it's convenient for you to build your own socket module, change
> it like this and see what happens (I'm looking at version 2.1 here.)

> *** socketmodule.c.dist Sun Apr 15 17:21:33 2001
> --- socketmodule.c      Thu Jun 20 10:10:12 2002
> ***************
> *** 597,602 ****
> --- 597,603 ----
>         case AF_UNIX:
>         {
>                 struct sockaddr_un *a = (struct sockaddr_un *) addr;
> +               a->sun_path[addrlen - (sizeof(*a) - sizeof(a->sun_path))] = 0;
>                 return PyString_FromString(a->sun_path);
>         }
>   #endif


> The address returned from recvfrom is (addr, len), but we've been
> ignoring len on the theory that the string would be NUL-terminated.
> It isn't, so there can be some garbage on the end.

> |  This is academic curiosity, and I'll read through the C sources
> |  to see what I can glean therefrom, eventually.  I'd like to know
> |  how I can tell what process has opened a connection to my 
> |  AF_UNIX socket and I'd love to know how to pass an open file
> |  descriptor through an AF_UNIX socket (in Python).  I've read that
> |  this is possible in C and that it is one of the few features of 
> |  AF_UNIX sockets which is NOT available via other address/protocol 
> |  families.

> Yes, AF_UNIX supports that (SOCK_DGRAM or SOCK_STREAM.)  See man 2
> sendmsg.  That would have to be added to the socket module.  Probably
> easy enough to do, as long as you confine yourself to support for this
> one particular thing (passing file descriptors.)

> |  ... I've also heard that this can be used as a way for a
> |  client to request read-only or append-only access to a file
> |  --- since the UNIX APIs (in C) apparently offer ways for the server
> |  to obtain credential information about the requesting process as
> |  well as passing open file descriptors (which are then roughly akin
> |  to "capabilities" since their access mode can't be changed)

> Don't know, right off hand I can't think what API function you
> might be thinking of there.
> 	Donn Cave, donn at u.washington.edu

 So, should this be reported to the Python dev list?  If so, how?
 Can we get it fixed by 2.3?  How would my code work if it was fixed?
 What would/should be returned for this case?