getpeername(2) on unix domain sockets?

[Chris Torek]

In article <2743 at ingr.UUCP> myoung at ingr.UUCP (Mark Young) writes:
>A test case on a bsd4.3 release demonstrates that a call to getpeername 
>specifying the fd for a unix domain socket returns success, with a 'namelen'
>that seems somewhat random.

Getpeername() on Unix domain sockets is broken in 4.3BSD.  The
behaviour you describe occurs on unconnected Unix domain sockets.
Getpeername() on connected Unix domain sockets crashes the machine.
Fixed in 4.3-tahoe, or apply the following to your kernel:

	[old]
	case PRU_PEERADDR:
		if (unp->unp_conn && unp->unp_conn->unp_addr) {
			nam->m_len = unp->unp_conn->unp_addr->m_len;
			bcopy(mtod(unp->unp_conn->unp_addr, caddr_t),
			    mtod(m, caddr_t), (unsigned)m->m_len);
		}
		break;

	[new]
	case PRU_PEERADDR:
		if (unp->unp_conn && unp->unp_conn->unp_addr) {
			nam->m_len = unp->unp_conn->unp_addr->m_len;
			bcopy(mtod(unp->unp_conn->unp_addr, caddr_t),
			    mtod(nam, caddr_t), (unsigned)nam->m_len);
		} else
			nam->m_len = 0;

>I did note, however, that the function getsockname(2) does indeed list as 
>a bug:
>
>	Names bound to sockets in the UNIX domain are inaccessible;  
>	'getsockname' returns a zero length name.

The manual entry is wrong on both counts (not surprising)---the 4.3BSD
distribution kernel leaves the name length unmodified, due to another
kernel bug.  Right above the case PRU_PEERADDR, you will find

	case PRU_SOCKADDR:
		break;

which should read

	case PRU_SOCKADDR:
		if (unp->unp_addr) {
			nam->m_len = unp->unp_addr->m_len;
			bcopy(mtod(unp->unp_addr, caddr_t),
			    mtod(nam, caddr_t), (unsigned)nam->m_len);
		} else
			nam->m_len = 0;
		break;

(exactly analagous to the case for PRU_PEERADDR).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris