Re: struct sockaddr_storage issues

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Fri, 23 Dec 2022 15:58:27 -0500 (EST)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> If you think that's broken, well, I disagree, but you can always
> send-pr it and let NetBSD decide on its position.
> 
I don't think it's broken, just something that is a bit clunky and
needs workarounds for AF_INET, AF_INET6, etc. See this bug report
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144231
I agree with the bug submitter and think that EINVAL should be relaxed
and handled better. Although I'm not insisting NetBSD make any changes
to current behaviour, just wanted to find out if this was a bug or not.

> Two more portability notes:
> 
> (1) You likelky will want to set the sin_len and sin6_len fields on
> systems that have them.  At a quick glance I see only one place where
> NetBSD cares about sin_len fields, that being in the code backing IDENT
> lookups, but I think I see a place where it may matter for AF_LOCAL, I
> haven't even looked at IPv6, and in any case there may be places I
> missed.  It also would surprise me if there weren't systems out there
> that cared more.  In your code, depending on addr's storage duration,
> you may be getting zero for sin_len and sin6_len or you may be getting
> stack trash.
>
I don't think you're quite correct here. The length member is not even
mandated by Posix. Below is copied verbatim from Richard Stevens
"Network Programming V1" book:

"Even if the length field is present, we need never set it and need
never examine it, unless we are dealing with routing sockets (Chapter
18). It is used within the kernel by the routines that deal with socket
address structures from various protocol families (e.g., the routing
table code).
The four socket functions that pass a socket address structure from the
process to the kernel, bind, connect, sendto, and sendmsg, all go
through the sockargs function in a Berkeley-derived implementation (p.
452 of TCPv2). This function copies the socket address structure from
the process and explicitly sets its sin_len member to the size of the
structure that was passed as an argument to these four functions. The
five socket functions that pass a socket address structure from the
kernel to the process, accept, recvfrom, recvmsg, getpeername, and
getsockname, all set the sin_len member before returning to the
process."

> (2) For AF_INET, you also really want to make sure the sockaddr_in is
> all zero bits before filling it.  If your addr variable has static
> storage duration and you never reuse it, your code is OK in this
> respect, and it is a broken requirement, but it _is_ a requirement in
> practice for at least some uses, so it likely behooves you to do the
> bzero (or equivalent) before filling in the values.  (I once looked at
> eliminating that misfeature.  At the time, it would have required
> significant kernel-internal overhaul.  When I write code which fills in
> structs sockaddr_in, I bzero, though I do comment "XXX API botch".)
> 
You may be right here, thanks for the info.