Subject: Re: SO_PEERNAME
To: None <tech-kern@netbsd.org>
From: William E. Baxter <web@superscript.com>
List: tech-kern
Date: 08/25/2001 13:01:38
On Sat, Aug 25, 2001 at 08:37:31AM -0700, Matt Thomas wrote:
> At 12:12 PM 8/25/2001 +0200, Emmanuel Dreyfus wrote:
> >Linux uses getsockopt to make a few extra informations available to the
> >calling process. This include for example who connected to the other
> >side of a UNIX socket, using the SO_PEERNAME getsockopt argument.
>
> We already have a better feature by having the kernel supply the
> credentials of the sending process. That makes SO_PEERNAME unneeded
> See SCM_CREDS.
Unfortunately, SCM_CREDS mechanisms pass credentials to the server only when the
client sends data. Thus the server cannot obtain credentials unless the client
offers them. By spawning connections and never sending data, a local user can
consume connections and deny service anonymously. Moreover, many servers
require credentials alone, and no data.
A while back I wrote a patch to implement a getpeereid() system call that
satisfies the following conditions:
1. Server can obtain credentials of connect() caller.
2. Server can obtain credentials without depending on client to send data.
The patch is out of date now, but probably not difficult to adapt (and I plan to
do so in my copious free time). Links to the patch and explanatory material
appear at
http://www.superscript.com/ucspi-ipc/getpeereid.html
Given getpeereid(), one can almost trivially create privileged servers that run
behind unix sockets, in an environment under their own control. In many cases
one can replace setuid programs with such servers. My ucspi-ipc package
provides a general framework for turning filters into local-domain servers based
on getpeereid(). The package is available at:
http://www.superscript.com/ucspi-ipc/intro.html
For simple examples of servers, see:
http://www.superscript.com/ipctools/intro.html
So far as I know, the current kernel lacks sufficient support to implement
getpeereid(). In particular, SCM_CREDS meets condition (1) but fails to meet
condition (2). Can anyone demonstrate a means to satisfy both conditions using
existing kernel facilities?
If you think that getpeereid() or sufficient basis for it should appear in the
kernel, tell the implementors. My patch remains theirs for the asking.
W.