Date: Tue, 8 Aug 2000 11:24:26 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: bright@wintelcom.net (Alfred Perlstein) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: getpeereid() syscall patch for FreeBSD 4.0 Message-ID: <20000808182426.4AE3037B5AE@hub.freebsd.org> In-Reply-To: <20000808093527.D4854@fw.wintelcom.net> from Alfred Perlstein at "Aug 8, 2000 09:35:28 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> * William E. Baxter <web@superscript.com> [000808 09:27] wrote: > > A patch implementing a getpeereid() syscall in FreeBSD 4.0 is > > available at > > > > http://www.superscript.com/patches/freebsd_4_0.getpeereid > > > > A local-domain server uses getpeereid() to obtain client credentials. > > Based on getpeereid() I created ucspi-ipc, a local-domain analogue to > > Dan Bernstein's ucspi-tcp. The project came about after I read the > > "Wiping out setuid programs" discussion the the BugTraq archives. At > > present, ucspi-ipc runs on patched OpenBSD, patched FreeBSD, and on > > Linux kernels that support SO_PEERCRED with getsockopt(). > > I haven't used the credential passing feature of sendmsg(), but I > was wondering what advantages this has over being able to pass > kernel verified id's through a unix domain socket using SCM_CREDS. > My reading of UNP seems to indicate that it offers the same features. The implementation of SCM_CREDS in FreeBSD is my doing, and I did it that way for a reason. At the time, I wanted a way to perform RPCs via UNIX domain sockets and have the server know with reasonable certainty the identity of the client. And I wanted to do it without using AUTH_DES authentication because I was trying to bootstrap AUTH_DES authentication in keyserv. The problem is that RPCs are by definition messages. Things are handled at the application layer on a per-message basis, not on a per-socket basis, even for TCP connections. The problem with having credentials established once when a socket is opened is that the client process can conceivably fork, at which point you will have two clients sharing one socket with the same credential data. This isn't likely, but it's possible, and it bothered me. By having the credentials inserted into the message each time by each process, there's no ambiguity, even though you only have one socket. However this may not be the ideal solution for everyone. You may be satisfied with the "create credentials once when you open the socket" method, in which case the best thing is to support both approaches with hopefully similar code. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000808182426.4AE3037B5AE>