From owner-freebsd-hackers  Tue Aug  8 11:24:28 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id 4AE3037B5AE; Tue,  8 Aug 2000 11:24:26 -0700 (PDT)
Subject: Re: getpeereid() syscall patch for FreeBSD 4.0
In-Reply-To: <20000808093527.D4854@fw.wintelcom.net> from Alfred Perlstein at "Aug 8, 2000 09:35:28 am"
To: bright@wintelcom.net (Alfred Perlstein)
Date: Tue, 8 Aug 2000 11:24:26 -0700 (PDT)
Cc: freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20000808182426.4AE3037B5AE@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> * 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