Set correct sockaddr length for abstract addresses

[rblaze]

There are three types of unix sockets [in Linux]: pathname, unnamed and abstract, see unix(7) for details. It is okay to use long sockaddr len with the pathname, which is null-terminated, and unnamed, which has no name.

But sun_path in the abstract sockaddr is effectively a blob, and sockaddr length must be set correctly. Otherwise, the connection fails.

Good strace:

9963  connect(4, {sa_family=AF_UNIX, sun_path=@"/tmp/dbus-fGvREc7jlQ"}, 23 <unfinished ...>

Bad strace:

connect(4, {sa_family=AF_UNIX, sun_path=@"/tmp/dbus-fLBigq6VT1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 110 <unfinished ...>

[kazu-yamamoto]

Relating to #306

[kazu-yamamoto]

@vdukhovni @JonCoens Could you review this PR?

[vdukhovni]

The abstract sockets are a Linux-specific feature. Should support for this also be Linux-specific? Is there any evidence of support for such unix-domain sockets on any of the BSDs, or other unix-like system?

[ By the way, it is rather unfortunate that the path associated with a unix-domain socket SockAddrUnix is a String and not a ByteString. Calling length here is only correct, because when binding the socket we later truncate all the Chars to CChars. Using ByteString here would have been a better interface. ]

[vdukhovni]

Also at around line 1019, I don't see any effort to decode abstract socket addresses correctly. Is there a portable way to distinguish empty paths from abstract socket addresses? Presently it looks like they'll return an empty path from accept() , getsockname() and getpeername(). If these are to be supported, surely not just connect(), sendto() and bind() should work, but also accept(), getsockname(), getpeername and recvfrom() for datagram sockets.

[rblaze]

Gentle ping.
Abstract sockets are used, for instance, by dbus-daemon when configured so, and this issue breaks support for said configuration in https://github.com/rblaze/haskell-dbus.

[vdukhovni]

Will you be addressing the review comments?

[rblaze]

I'm just reverting parts of the #306 which broke things. This change would unbreak abstract sockets support and enable dbus library builds with the latest network versions.

If there was no support for getting proper addresses (I checked), I feel adding new features is out of scope for this diff.

[vdukhovni]

If abstract sockets are supported, they need to work correctly. Making them work not only for the system calls that take addresses, but also for the system-calls that return addresses is not a new feature. Also if the abstract sockets are Linux-specific, then the logic to support them needs to be specific to Linux, lest it break other platforms.

Once you open the can of worms you should deal with all the issues that present themselves, leaving the code in a known correct state.

[vdukhovni]

Some tests of support for abstract sockets would also reduce opportunities for future regressions.

[eborden]

I fully support adding tests. I'd love to land #375 before that, since it is causing a lot of churn in the test modules.

[kazu-yamamoto]

OK. @rblaze wants to fix this regression and other stuffs are not his responsibility.
I opened #377 to brush up the support of abstract addresses.

I will merge this PR with #ifdef.

[kazu-yamamoto]

I will add #ifdef

[kazu-yamamoto]

Merged.
@rblaze Would you check and close this if OK.

[rblaze]

@kazu-yamamoto Thank you! This works just fine.