[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unfilled path in getsockname() for unix sockets
From: |
Samuel Thibault |
Subject: |
Re: unfilled path in getsockname() for unix sockets |
Date: |
Sun, 4 Dec 2011 14:22:58 +0100 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
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