[Bug 248614] getpeereid.3 says listen where it means accept.

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248614

            Bug ID: 248614
           Summary: getpeereid.3 says listen where it means accept.
           Product: Documentation
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Manual Pages
          Assignee: bugs at FreeBSD.org
          Reporter: gnachman at gmail.com
                CC: doc at FreeBSD.org

Created attachment 217167
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=217167&action=edit
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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.