[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unfilled path in getsockname() for unix sockets
From: |
Pino Toscano |
Subject: |
Re: unfilled path in getsockname() for unix sockets |
Date: |
Sun, 4 Dec 2011 16:45:20 +0100 |
User-agent: |
KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) |
Alle domenica 4 dicembre 2011, Samuel Thibault ha scritto:
> 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.
Hmm :-/ And there's really no way to get it later?
> > 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.
Yes, I knew sun_path was rather short, my doubt was whether which was a
"better" return value, as usually socket functions return values of the
whole sockaddr_* structs.
> > [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.
I guess so.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.