Libc getnameinfo length requirement

[Christophe Beauval]

Hello

There is a typo in the comment: RFC 4018 is mentioned, this should be 4038.

There is also a problem with relying on the sa->sa_len presence and sort 
of undoing two earlier patches from 17th April 2005, where according to 
the commit comment, sa->sa_len is not required by POSIX: 
https://github.com/freebsd/freebsd/commit/90a7ec34ec2cf5e36aeb76ff35c656f880659274#diff-25ee506a989a23ae5d8904e113aa66d7 
and 
https://github.com/freebsd/freebsd/commit/ba35b6aa7602967dbfeb53dc1e32ba1868bd3e98#diff-25ee506a989a23ae5d8904e113aa66d7 
.

Kind regards

Christophe Beauval


Op 2/03/2018 om 3:18 schreef Hiroki Sato:
> Hi,
>
> Christophe Beauval <christophebeauval at hotmail.com> wrote
>    in <VI1PR0402MB371177DFA52E8CC936FCDD00A2C60 at VI1PR0402MB3711.eurprd04.prod.outlook.com>:
>
> ch> Hello all
> ch>
> ch> This message after having presented the problem below in the freenode
> ch> #freebsd and EFNet #bsdcode channels and being advised (amongst others)
> ch> to use this mailing list.
> ch>
> ch> When I got strange errors (EAI_FAIL) from getnameinfo-calls in a private
> ch> project, I investigated the freebsd/libc/net/getnameinfo.c source code
> ch> and stumbled upon the requirement (in the switch-statement at line 127)
> ch> that the "socklen_t salen" argument needs to be the exact same number as
> ch> "sizeof(struct sockaddr_in)" for the PF_INET protocol family and
> ch> "sizeof(struct sockaddr_in6)" for the PF_INET6 protocol family. This
> ch> fails when using a "sockaddr_storage" struct as first argument and tied
> ch> to this a "sizeof(struct sockaddr_storage)" as second argument, as can
> ch> be found as example in RFC 4038 on page 21 paragraph 6.2.3. For the
> ch> PF_LOCAL protocol family a larger "salen" than it's used struct is also
> ch> not allowed in that switch.
> ch>
> ch> A less strict requirement either allowing any larger size (like in
> ch> glibc's implementation) or at least the size of "struct
> ch> sockaddr_storage" (as suggested by hrs) would solve this problem.
>
>   I have a patch to change getnameinfo() to accept a longer salen
>   (attached).  I do not think there is a bad side-effect or impact for
>   backward compatibility.  You can try test_getnameinfo.c to test the
>   difference.
>
>   While I'm here, I changed the return value on error because SUSv4
>   says EAI_FAMILY should be returned when the address length was
>   invalid.
>
> -- Hiroki