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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248614 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=3D217167&action= =3Dedit 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 t= he peer on the socket for which *listen* has been called? There isn't a peer u= ntil you `accept`. Using the attached server and client programs, it looks like my intuition is correct: $ ./server status=3D-1 eid=3D0 errno=3D57 status=3D0 eid=3D1001 errno=3D57 `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 accept= 4(2). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248614-227>