Date: Thu, 28 Jun 2001 10:56:09 -0500 From: "Jacques A. Vidrine" <n@nectar.com> To: Dima Dorfman <dima@unixfreak.org> Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket Message-ID: <20010628105609.K30889@madman.nectar.com> In-Reply-To: <20010627070628.AB5F13E2F@bazooka.unixfreak.org>; from dima@unixfreak.org on Wed, Jun 27, 2001 at 12:06:28AM -0700 References: <20010627070628.AB5F13E2F@bazooka.unixfreak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 27, 2001 at 12:06:28AM -0700, Dima Dorfman wrote: > Currently, there is no reliable way for a server listening on a Unix > domain socket to find out the credentials of its peer until the peer > sends something over the socket. > > 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)). > > Patch attached. > > Comments? Suggestions? What possible actions could the server take upon determining the credentials of the client? Either drop the connection or go forward. Why not just create the domain socket with permissions such that only authorized clients can connect to them in the first place? I suspect you'd answer that it isn't fine-grained enough, to which I would probably suggest that maybe the application can stand a wee bit more design work :-) or that ACLs could make it fine-grained enough. Or maybe I've missed something entirely. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org 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?20010628105609.K30889>