Date: Wed, 12 Aug 2020 09:06:54 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248614] getpeereid.3 says listen where it means accept. Message-ID: <bug-248614-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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@FreeBSD.org Reporter: gnachman@gmail.com CC: doc@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 the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248614-227>