On Sat Jun 3 22:38:31 2023 +0000, Ally Sommers wrote:
Windows indeed does not modify the path. `getpeername` and `getsockname` return the original path, even if it is relative or prefixed. Notably, Windows itself does not implement `accept` correctly, as it does not fill in the path but does set `sun_family` to `AF_UNIX`. I think punting on `getpeername` with regard to Windows <-> Unix sockets is fine since there is absolutely no precedent there and Wine doesn't even have the infrastructure to test a resolving implementation, but `getpeername` correctly returning the path of Windows-created AF_UNIX sockets should be implemented, in this or a following merge request. Given this, I reaffirm my opinion that forwarding `getpeername` to `sock_ioctl` is the cleanest way to handle this, and my next push will include an implementation of that. I can split it off into its own merge request if the changes made are deemed too extensive to be included here.
Wow, that is awkward.
I would opine that getpeername() should be stubbed out for all AF_UNIX sockets, regardless of who created the peer. Even if it's possible to trace the peer back to a struct sock, it strikes me as an extra bit of complication that probably won't be used.