From owner-freebsd-arch Sun Jul 8 1:31:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 27BDA37B406 for ; Sun, 8 Jul 2001 01:31:10 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 07E883E28; Sun, 8 Jul 2001 01:31:06 -0700 (PDT) To: David Malone Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket In-Reply-To: <200107041056.aa84171@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on "Wed, 04 Jul 2001 10:56:02 +0100" Date: Sun, 08 Jul 2001 01:31:05 -0700 From: Dima Dorfman Message-Id: <20010708083106.07E883E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Malone writes: > > Here's one example use: http://www.superscript.com/ucspi-ipc/intro.html. > > This author actually provides patches for *BSD to implement getpeereid(), > > and I believe--although I haven't checked--that OpenBSD just took his > > patch. (And as I said before, I really think a system call is overdoing it > > for something like this, esp. when there's already a nice socket option > > interface.) > > Interesting - I guess this is a little like the inetd unix domain > socket stuff, only it sets some extra environment variables. I > guess it would make sense to have inetd set these variables too. > > I see some mention of SO_PEERCRED for Linux - we should probably > find out what was done here and impliment something compatable? I looked at what Linux does today (via code inspection only; I don't have spare hardware for a Linux box). Essentially it's what I implemented; the SO_PEERCRED socket option transfers the pid, uid, and gid to the peer. The credentials are set on connect(2) *and* listen(2); this means that both sides can get each other's credentials. I didn't implement this, but it might be nice. > (Least we be accused of suffering from NIH). We could then also > impliment getpeercred in terms of this It's getpeereid, and it's quite trivial. > and impliment the BSDI socket > option. This shouldn't be very hard, either. > That should cover most bases. > > > > Do we know the intended uses of any of other options which > > > people have implimented? > > > AFAIK, they aren't using it (read: I haven't seen any commit logs that > > suggest they're using it, although OpenBSD's commit logs are > > notoriously terse), and I don't know what their intented uses are. > > I'll try grepping for it in the OpenBSD CVS tree and see. I grep'd a day ago; they're not using it. So, I think the best course of action is to (1) extend my implementation to work for the connect(2) caller as well (i.e., allow the client to verify the server's credentials), (2) implement getpeereid, and (3) add the LOCAL_CREDS option (note that NetBSD has this, too). I'll do (1) and (2) in a day or so; would you like to do (3), or shall I? As an aside, any ETA on those af_unix fixes you mentioned? Thanks, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message