Date: Tue, 03 Jul 2001 20:25:29 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Dima Dorfman <dima@unixfreak.org> Cc: arch@freebsd.org, dwmalone@maths.tcd.ie Subject: Re: Peer credentials on a Unix domain socket Message-ID: <200107032025.aa14647@salmon.maths.tcd.ie> In-Reply-To: Your message of "Wed, 27 Jun 2001 00:06:28 PDT." <20010627070628.AB5F13E2F@bazooka.unixfreak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. (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.) David. 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? <200107032025.aa14647>