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: [email protected]
          Reporter: [email protected]
                CC: [email protected]

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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-doc
To unsubscribe, send any mail to "[email protected]"

Reply via email to