-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SockaddrStorage
broken for variable-length addresses
#1866
Comments
I see. This isn't a problem on BSDs, where sockaddr_storage does know its own size. That's probably why I never noticed this before, because that's where I do most of my development. UnixAddr already has a workaround for Linux-like OSes, and a similar workaround is probably needed for SockaddrStorage. As far as you know, is the problem limited to Unix-domain socket addresses? |
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
Unfortunately I have no experience with any BSDs, so I can see how it's a pain trying to abstract around both socket address implementations.
I think so, I don't know of any other variable-length socket addresses on Linux, but there are a lot of protocol families I've never used. |
1871: Fix using SockaddrStorage to store Unix domain addresses on Linux r=rtzoeller a=asomers Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes #1866 Co-authored-by: Alan Somers <asomers@gmail.com>
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes #1866
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
Since it has variable length, the user of a sockaddr_un must keep track of its true length. On the BSDs, this is handled by the builtin sun_len field. But on Linux-like operating systems it isn't. Fix this bug by explicitly tracking it for SockaddrStorage just like we already do for UnixAddr. Fixes nix-rust#1866
The
SockaddrStorage
type "forgets" the address length, which causes incorrect and unexpected behaviour. I think this is a more fundamental issue with how nix represents socket addresses.Example:
If we look at the strace, we can see that nix is proving the wrong sockaddr length to
connect()
, which represents an incorrect address. This is equally important for abstract named and unnamed unix sockets.When you're writing code that has to support many different socket address types, this means that
SockaddrStorage
is unusable. We're currently sticking with the deprecatednix::sys::socket::SockAddr
for now as it doesn't have this issue.The text was updated successfully, but these errors were encountered: