As described in unix(7) manpage, Linux allows for 
special "kernel namespace" AF_UNIX sockets defined. 
With such sockets, the first byte of the path is \x00, 
and the rest is the address. These sockets do not show 
up in the filesystem.
socketmodule.c:makesockaddr (as called by recvfrom) 
uses code like
PyString_FromString(a->sun_path)
to retrieve the address. This is incorrect -- on Linux, if 
the first byte of a->sun_path is null, the function should 
use PyString_FromStringAndSize to retrieve the full 108-
byte buffer.
I am not entirely sure that this is the only thing that 
needs to be fixed, but bind() and sendto() work with 
these sort of socket paths just fine.

Logged In: YES 
user_id=29957

Eek. What a totally mental design decision on the part of
the Linux kernel developers. Is there a magic C preprocessor
symbol we can use to detect that this insanity is available? 

(FWIW, Perl also has problems with this:
http://www.alexhudson.com/code/abstract-sockets-and-perl
)

Logged In: YES 
user_id=1057404

The below patch adds the functionality if UNIX_PATH_MAX is
defined (in Linux it's in sys/un.h).

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:08:47 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

Logged In: YES 
user_id=1057404

Also checks for "linux" to be defined, on Mondragon's
recommendation.

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:17:51 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX) && defined(linux)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX && linux */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

Logged In: YES 
user_id=11375

Should it use UNIX_PATH_MAX as the length of the string, or
1+ strlen(a->sun_path+1)?  (The leading null byte, plus the
following null-terminated string?)

Logged In: YES 
user_id=595126

"""The socket’s address in this namespace is given by the
rest of the bytes in sun_path.  Note that names in the 
abstract namespace are not zeroterminated."""

The length would be UNIX_PATH_MAX in this case.

Logged In: YES 
user_id=1057404

It should use UNIX_PATH_MAX, but it should also check that
the length of the buffer supplied is correct, my bad.

Logged In: YES 
user_id=129426

Patch is at 1062014

The comments below state that UNIX_PATH_MAX is defined in
sys/un.h, but it isn't. The patch gets it in another
(hopefully portable) way (and also exposes it as a new
constant in the socket module)

Logged In: YES 
user_id=4771

I'm about to check in a slightly different patch
(also at 1062014) which tries to preserve the length
of the abstract namespace addresses (the kernel saves
this length even though it is not zero-terminated,
so that the names '\x00abc' and '\x00abc\x00' and
'\x00abc\x00\x00' are all different in theory).
The patch no longer exposes UNIX_PATH_MAX because
I'm not sure it's useful any more.  If anyone who
is relying on this Linux extension more than myself
has comments, now would be a good time :-)