> 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.

Except for Linux API compatability, I'd prefer to see a better name.
SO_PEERNAME sounds like an alias for getpeername(), which it isn't.

>> 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.

This is not a big deal; you just define the protocol in question to
begin with the client sending something.

> By spawning connections and never sending data, a local user can
> consume connections and deny service anonymously.

There's no reason that PRU_CONNECT (or maybe unp_connect()) couldn't be
tweaked so that if the listening socket is set WANTCRED, a zero-length
message with SCM_CREDS is generated as part of the connect() operation
and is therefore available to the server immediately after accept().

> Moreover, many servers require credentials alone, and no data.

If the cost of a zero-byte send with SCM_CREDS is too high, I submit
sockets are a wrong IPC mechanism to use anyway. :-)

> 1. Server can obtain credentials of connect() caller.
> 2. Server can obtain credentials without depending on client to send data.

> 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).

I don't think it does meet condition 1.  SCM_CREDS sends the
credentials of the process doing the sendmsg, right?  (That's what the
code I have at hand appears to do.)  This does not necessarily bear any
relationship to the credentials of the process that did the connect,
either then or (if it still exists) now.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B