Re: unfilled path in getsockname() for unix sockets

[Samuel Thibault]

Pino Toscano, le Sun 04 Dec 2011 13:14:52 +0100, a écrit :
> while debugging, I apparently stumbled upon a bug of getsockname() for a 
> bound unix socket, as also the attached test program shows: sun_path is 
> left unfilled, as also the comment of S_socket_whatis_address() in 
> hurd/pflocal/pf.c would suggest.

Which is a design choice, apparently: only glibc's bind.c knows about
the socket path.

> There's also another possibly weird behaviour in that: 
> S_socket_whatis_address() sets its sockaddr_len parameter in what seems 
> also what Linux does, ie
>   offsetof(struct sockaddr, sa_data) + strlen(sun_path) + 1
> instead of sizeof(struct sockaddr_un),

Yes, because the size of the sun_path member is rather indicative only
(and relatively small: 108 only!). Everything should also be working
with bigger paths, so it does not really make sense to return the
arbitrary size of sockaddr_un.

> [1] in perl's code, I've seen this snippet:
> unpack_sockaddr_un(sun_sv)
> [...]
> #   ifndef __linux__
>         /* On Linux sockaddrlen on sockets returned by accept, recvfrom,
>            getpeername and getsockname is not equal to sizeof(addr). */
>         if (sockaddrlen != sizeof(addr)) {
>             croak("Bad arg length for %s, length is %d, should be %d",
>                         "Socket::unpack_sockaddr_un",
>                         sockaddrlen, sizeof(addr));
>         }
> #   endif

I'd say restrict to !__GNU__ too, then.

Samuel