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