Re: [PATCH v11 0/6] MR2786: Add support for AF_UNIX sockets

[Zebediah Figura (＠zfigura)]

On Thu Jun  1 23:00:29 2023 +0000, Ally Sommers wrote:
> > I'd also like to see the result of getsockname() on all tested paths.
>
> On Windows, `getsockname` returns the path provided to `bind` when
> called on an AF_UNIX socket. Since it would be impossible to provide a
> Windows path to the native `bind` call, this must be emulated.
> > What protocol do these sockets actually have? I.e. what does
>
> SO_PROTOCOL_INFO return for them? 0 is usually a wildcard.
> Windows returns the following:
> dwServiceFlags1:        0x00020026 // (XP1_GUARANTEED_DELIVERY |
> XP1_GUARANTEED_ORDER | XP1_IFS_HANDLES)
> dwServiceFlags2:        <reserved>
> dwServiceFlags3:        <reserved>
> dwServiceFlags4:        <reserved>
> dwProviderFlags:        8
> ProviderId:             <GUID>
> dwCatalogEntryId:       1007
> ProtocolChain:          { ChainLen: 1, ChainEntries: { 0 } }
> iVersion:               2
> iAddressFamily:         1
> iMaxSockAddr:           110
> iMinSockAddr:           2
> iSocketType:            1
> iProtocol:              0
> iProtocolMaxOffset:     0
> iNetworkByteOrder:      0
> iSecurityScheme:        0
> dwMessageSize:          0
> dwProviderReserved:     <reserved>
> szProtocol:             AF_UNIX

Interesting. So it really does have a protocol of zero, but also PFL_MATCHES_PROTOCOL_ZERO, which is mildly weird but I guess probably works without any special casing.

The rest looks pretty predictable.