Bug 248614 - getpeereid.3 says listen where it means accept.
Summary: getpeereid.3 says listen where it means accept.
Status: New
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Gordon Bergling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-12 09:06 UTC by George Nachman
Modified: 2020-08-14 19:09 UTC (History)
2 users (show)

See Also:


Attachments
Client and server that demonstrate the actual behavior of getpeereid (2.10 KB, text/plain)
2020-08-12 09:06 UTC, George Nachman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description George Nachman 2020-08-12 09:06:54 UTC
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:

$ ./server
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).
Comment 1 Conrad Meyer freebsd_committer 2020-08-12 22:11:08 UTC
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?)
Comment 2 George Nachman 2020-08-14 03:36:44 UTC
> 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.