[PATCH 4/7] Add support for receiving fds in replies

[Mouse]

>>> Same comment about not using the CMSG_ API properly.
>> Same comment about it being a broken API; I would say it's broken
>> enough that it's not possible to use it properly.
> It's horrible, yes.  And you're right, CMSG_LEN/CMSG_SPACE was broken
> on NetBSD for quite a while.  But that was finally fixed about 2
> years ago.

It's the API I think is broken, not any particular implementation of
it.

>> [...] the property that, upon receiving a message with file
>> descriptors in it, all the descriptors would arrive in the recipient
>> process's open file descriptors table even if their actual numbers
>> were dropped for MSG_CTRUNC reasons; [...]

> Since we were pretty horrified by the mess, we actually put some
> restrictions on fd passing in OpenBSD:
> [...]
> 2. When there is not enough room to receive all file descriptors,
>    recvmsg(2) will simply fail and accept no file descriptors instead
>    if returning sucessfully and setting MSG_CTRUNC.

In what you describe, what happens to the descriptors?  Are they closed
when recvmsg finds insufficient room, or are they held pending a later
recvmsg() with enough cmsg space, or what?  It looks to me as though
this wedges communication entirely if there are more descriptors in the
message than the max the receiver is prepared to accept.

I think what NetBSD did was to receive what there's room for, dropping
any fds there isn't room for, but truly dropping them, rather than the
former behaviour of receiving the fds but dropping their numbers.

That is, if the sender sends (say) four descriptors when the receiver
provides room for only two ints, the old behaviour would have all four
descriptors arrive in the open file table, two of their numbers go into
the buffer, and MSG_CTRUNC set.  The new behaviour has two descriptors
arrive in the open file table and the control data buffer, with the
other two descriptors being closed, and MSG_CTRUNC set.

> Note that it looks like this was indeed the right decision, as 2)
> actually protects OpenBSD from the file descriptor leaks in Keith's
> current libxtrans code.

So does the current NetBSD way (well, mutatis mutandis).  I can think
of at least one other reasonable way to address the issue, too, so I'm
far from convinced there is a "_the_ right decision" here.

> I think the only reasonable thing to do here is disable the file
> descriptor passing on systems where file descriptor passing is
> (still) broken like that.

Perhaps fortunately for X, it's easy to test for if you don't mind
building and running a test program - which, since X seems to have now
drunk the autoconf koolaid :(, I infer is not a problem.

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