Date: Wed, 04 Jul 2001 10:02:35 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Dima Dorfman <dima@unixfreak.org> Cc: David Malone <dwmalone@maths.tcd.ie>, arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket Message-ID: <200107041002.aa78002@salmon.maths.tcd.ie> In-Reply-To: Your message of "Tue, 03 Jul 2001 14:06:25 PDT." <20010703210625.B09E53E28@bazooka.unixfreak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. What we have is slightly different. In BSDI's version you set a socket option on the receiving end and then cerds are added as a control message when someone writes data to the sending end. With our version the sender must add a control message of type SCM_CREDS. > > 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 need to communicate after authenticating then you can always send a datagram back with one end of a pipe, a socketpair or whatever type of file discriptor you need. Mind you, I may just be making excuses... > > (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 :-). If we wanted to be consistant with the tcp/udp getcred code we should be getting the creds of the person who did the socket(2) call ;-) I guess it's a matter if figuring out what the likely uses are and what the most sensible semantics are based on those. I was working on making a non-suid version of crontab[*] which used SCM_CREDS and SCM_RIGHTS. I was using a datagram socket 'cos it avoided the problem of having to listen and accept. In this case, having the credentials attached to the data you recieve means that there was less doubt about who made the request. I wonder how OpenBSD are using getpeerid and what it's semantics are? Do we know the intended uses of any of other options which people have implimented? (Maybe we should just impliment a way of getting the creds of the caller of socket, connect or write and let application writers choose). David. [*] I got stuck implimenting this version of crontab 'cos currently you can only attach one control message at a time. I've fixed this and found three reasonably serious bugs in the control message passing code (two only show up on FreeBSD-alpha, I think all the BSDs get bitten by the other). Patches soon, hopefully. 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? <200107041002.aa78002>