It looks to me as though sending file descriptors (control data of type
SCM_RIGHTS) is partially broken in 2.0 on architectures where
__cmsg_alignbytes() is not sizeof(int)-1.

Specifically, RFC3542 says that msg_controllen may include padding
after the last control message (which in our implementation means
padding to the boundary determined by __cmsg_alignbytes()).  But if I
do this, the test in unp_internalize() that tests for
cm->cmsg_len != control->m_len fires, because cm->cmsg_len is the
CMSG_LEN() value whereas control->m_len is the CMSG_SPACE() value.

Setting msg_controllen to the CMSG_LEN() value makes the error go away,
which leads me to think my analysis is right.  (Presumably sending a
second file descriptor would also have this effect, though I haven't
tested that.)

Am I smoking crack, or is this a real bug?  It looks to me as though
the test in unp_internalize should read cm->cmsg_len > control->m_len
to allow for padding.

/~\ 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