Created attachment 217167 [details]
Client and server that demonstrate the actual behavior of getpeereid
The manpage for `getpeereid` states:
> The argument s must be a UNIX-domain socket (unix(4)) of type SOCK_STREAM on which either connect(2) or listen(2) have been called.
This is surprising! Why would you be able to get the effective user ID of the peer on the socket for which *listen* has been called? There isn't a peer until you `accept`.
Using the attached server and client programs, it looks like my intuition is correct:
status=-1 eid=0 errno=57
status=0 eid=1001 errno=57
`getpeereid` requires s to be the socket that has been returned by `accept()`, not the one that was `listen()`ed on.
I think the language should be changed to:
> The argument s must be a UNIX-domain socket (unix(4)) of type SOCK_STREAM on which connect(2) has been called or was returned by accept(2) or accept4(2).
Probably connect(2) has to succeed, too, right?
Maybe we can simplify to "a connected UNIX-domain socket?"
(Does it really have to be SOCK_STREAM, either, or just any connectable socket type?)
> a connected UNIX-domain socket
This would have been better, since it's what I expected. It looks like they've added some new socket types that I'm not familiar with, so I won't comment on whether it's only SOCK_STREAM.