[ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific addressing

[SourceForge.net]

Bugs item #764437, was opened at 2003-07-02 00:13
Message generated for change (Comment added) made by ppergame
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Pergamenshchik (ppergame)
Assigned to: Nobody/Anonymous (nobody)
Summary: AF_UNIX sockets do not handle Linux-specific addressing

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Pavel Pergamenshchik (ppergame)
Date: 2004-07-07 07:37

Message:
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 zero‐terminated."""

The length would be UNIX_PATH_MAX in this case.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 07:04

Message:
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?)

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 12:16

Message:
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 */
###

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 12:06

Message:
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 */
###

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-11-25 00:13

Message:
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
)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470