Date: Tue, 03 Jul 2001 14:06:25 -0700 From: Dima Dorfman <dima@unixfreak.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket Message-ID: <20010703210625.B09E53E28@bazooka.unixfreak.org> In-Reply-To: <200107032025.aa14647@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on "Tue, 03 Jul 2001 20:25:29 %2B0100"
next in thread | previous in thread | raw e-mail | index | archive | help
David Malone <dwmalone@maths.tcd.ie> writes: > > I would like to propose implementing such a facility as a socket > > option, LOCAL_PEERCRED. The payload would be am xucred structure with > > the effective credentials of the connect(2) caller. Granted these may > > not be the credentials of the process using the socket (think > > descriptor passing), but it doesn't matter; if a process hands a > > descriptor off to something else, it should be trusting it not to > > abuse it (this is a feature: think of opening a privileged port and > > dropping privileges). > > BSDI already has an option like this called (I think) LOCAL_CREDS, > it would be probably best to impliment what they do. I think we already have this, although it isn't called LOCAL_CREDS. At least there's code to implement it in uipc_usrreq.c (unp_internalize() routine, circa line 991). If I'm seeing things, then LOCAL_CREDS would certainly be a welcome addition, although it would compliment, not contradict, what's being discussed here. > The option is > discussed in the second edition of Steven's network programming > book. I have some patches which clean up the Unix Domain control > message passing code, so I could have a look at implimenting it. > > > This has been discussed at least twice before, and nobody has a better > > idea. Again, I would like to stress the two requirements: (1) the > > accept(2) caller must be able to reliably obtain the effective > > credentials of the connect(2) caller, and (2) the accept(2) caller > > must be able to do (1) without relying on the connect(2) caller to > > send data (SCM_CREDS doesn't meet (2)). > > If you want to do things like this without waiting, then maybe it > would be better coded using unix domain datagram sockets, not stream > sockets? That way they can't use up file discriptors on the serving > process. They can still send junk datagrams, but you could tell > they were junk easily 'cos they'd have no credentials attached. But it may still be desireable to use a stream socket for other reasons. > (If you impliment things this way you can also get the creds of > the process sending messages, as opposed to the credentials of the > process which bound the socket.) With my implementation, the credentials are stored at connect(2) time. In some bizzare cases, this may even be preferred to the credentials at write(2) time. Of course, having both would be nice :-). Dima Dorfman dima@unixfreak.org P.S. I just caught up on my OpenBSD commit mail, and it seems they've implemented something like what I'm proposing, but as a system call, getpeereid(). The net result is the same, although I think a socket option is more appropriate than a syscall. If desired, we/I can implement getpeereid() as a library function in terms of getsockopt(2). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010703210625.B09E53E28>